Accessing encrypted information with a trusted device

ABSTRACT

In one embodiment, a method herein may comprise: receiving, at a first device, an encrypted private key of a second device encrypted using a public key of the first device, wherein the second device encrypts data into encrypted data using a public key of the second device and stored the encrypted data on a storage server: and decrypting, by the first device, a private key of the second device from the encrypted private key using a private key of the first device; and accessing, by the first device, the encrypted data on the storage server by utilizing the private key of die second device.

RELATED APPLICATION

This application claims priority to U.S. Prov. Appl. No. 63/312,598,filed Feb. 22, 2022, entitled USING MULTIPLE DEVICES FOR ACCESSINGCONCEALED INFORMATION, by Shmuel Shaffer, et al., the contents of whichare incorporated herein by reference.

TECHNICAL FIELD

The present disclosure relates generally to secure data storage systems,and, even more particularly, to accessing encrypted data with a trusteddevice.

BACKGROUND

Information privacy and security has always been an important subject incomputer technology, and is becoming even more imperative in today'stechnologically connected society. Identity theft is rampant, and thereis a constant battle between data storage and communication systemsagainst unscrupulous hackers coming from all over the world. Inparticular, passwords can be broken or stolen (e.g., through phishing orspear-phishing techniques), encryption techniques can be eavesdropped,reverse engineered, or outright broken, authorized account access can bespoofed, and many other methods can be taken by individuals or scores ofdirected computers (e.g., “bots”) to allow unsanctioned retrieval ofcommunicated or stored information. With the explosion of cloud-baseddata storage, in particular, moving the data from the endpoints into thenetwork adds another layer of data handling and thus necessaryprotection, with additional data transmission and storage locationsbeing vulnerable to attack and unsanctioned access.

In many instances, such information can be innocuous, such as publiclyavailable information or information generally acceptable to users to beshared (e.g., website cookies, search terms, etc.). However, in moreproblematic situations, this information can be harmful if obtained bythe wrong entity (e.g., hackers, “dark web” operators, and so on). Forexample, addresses, phone numbers, credit card numbers, bank accountnumbers, usernames, passwords, pins, social security numbers, and manyother pieces of information are generally considered to be fundamentally“secret” data that are to be shared only when necessary, and only onselect systems when a user is assured that the information will beconfidently kept private. “Personally identifying information” (PII), inparticular, can be used for stealing user identities, which can then beused to access further private information of the user (e.g., otheraccounts), or even to allow a hacker to withdraw funds from the user'sbank accounts, make fraudulent charges on credit cards, or apply forcredit under the guise of being the user. Other examples of data thatwould need to be secured include such things as legal paperwork,engineering plans, business or investment strategies, and so on.

In fact, in addition to these types of secure information, the volume ofdata that can be collected on a user, such as web surfing habits, onlineshopping habits, retail shopping habits, food shopping habits, traveland location generally, social media likes and dislikes, and so on,create an environment where many diverse types of end-users can benefitfrom the fact that there is truly so much data about users in general.Conventionally, control over who has access to this data is out of theuser's control. Moreover, while certain companies would love to haveaccess to this data (e.g., social media, advertising, etc.), othercompanies would prefer to not have the responsibility of keeping thisinformation in their local databases for fear of being hacked.

SUMMARY

The techniques herein are directed generally to a “zero-knowledge” datamanagement network. In particular, according to one or more embodimentsdescribed herein, users are able to share verifiable proof of dataand/or a limitless list of details about themselves (identifyinformation), and businesses are able to request, consume, and act onthe data, providing a hyper-personalized experience—all without a datastorage server or those businesses ever seeing or having access to theraw sensitive information. That is, the embodiments herein are directedto a decentralized network for trust, identity, privacy, andpersonalization that reinvents secure data storage and digitalidentities, where server-stored data is viewable only by the intendedrecipients, which may even be selected after storage of the data.

Specifically, in one embodiment, the techniques herein are directed tostoring encrypted data for access by a trusted device. For instance, anillustrative method herein may comprise: encrypting, by a first device,data into encrypted data using a public key of the first device;storing, by the first device, the encrypted data on a storage server;encrypting, by the first device, a private key of the first device intoan encrypted private key using a public key of a second device; andcommunicating, from the first device, the encrypted private key of thefirst device to the second device, wherein the second device isconfigured to access the encrypted data on the storage server based ondecrypting the encrypted private key of the first device by utilizing aprivate key of the second device and utilizing the private key of thefirst device to access the encrypted data stored on the storage server.

In another embodiment, the techniques herein are directed to accessingencrypted information with a trusted device. For instance, anillustrative method herein may comprise: receiving, at a first device,an encrypted private key of a second device encrypted using a public keyof the first device, wherein the second device encrypts data intoencrypted data using a public key of the second device and stored theencrypted data on a storage server: decrypting, by the first device, aprivate key of the second device from the encrypted private key using aprivate key of the first device; and accessing, by the first device, theencrypted data on the storage server by utilizing the private key of thesecond device.

Other embodiments of the present disclosure may be discussed in thedetailed description below, particularly from the perspective ofdifferent devices in a distributed storage and data management system,and the summary above is not meant to be limiting to the scope of theinvention herein.

BRIEF DESCRIPTION OF THE DRAWINGS

The embodiments herein may be better understood by referring to thefollowing description in conjunction with the accompanying drawings inwhich like reference numerals indicate identically or functionallysimilar elements, of which:

FIG. 1 illustrates an example simplified computer network;

FIG. 2 illustrates an example of a computing device;

FIG. 3 illustrates an example storage server environment;

FIG. 4 illustrates another example storage server environment,particularly in accordance with an example zero-knowledge datamanagement system herein;

FIG. 5 illustrates an example communication exchange between the devicesof the storage server environment as shown in FIG. 4 , particularly inaccordance with an example zero-knowledge data management system herein;

FIGS. 6A-6D illustrate examples of encrypting and decryptingcombinations for use with an example zero-knowledge data managementsystem herein;

FIG. 7 illustrates another representation of the encrypting anddecrypting combinations for use with an example zero-knowledge datamanagement system herein;

FIG. 8A illustrates an example storage system with multiple sets ofsource data and rekeying keys in accordance with an examplezero-knowledge data management system herein;

FIG. 8B illustrates the example storage system with multiple sets ofsource data and rekeying keys where certain sets of source data areassociated together in accordance with an example zero-knowledge datamanagement system herein;

FIG. 9 illustrates another example communication exchange between thedevices of the storage server environment, particularly with a pluralityof recipient devices in accordance with an example zero-knowledge datamanagement system herein;

FIGS. 10A-10D illustrate examples of encrypting and decryptingcombinations for recipient-based key rotations in accordance with anexample zero-knowledge data management system herein;

FIGS. 11A-11B illustrate examples of encrypting and decryptingcombinations for source-based key rotations in accordance with anexample zero-knowledge data management system herein;

FIGS. 12A-12B illustrate further examples of encrypting and decryptingcombinations for source-based key rotations in accordance with anexample zero-knowledge data management system herein;

FIG. 13 illustrates an example of sharing authorization rules inaccordance with an example zero-knowledge data management system herein;

FIG. 14 illustrates an example of authorization and authenticationcommunications in accordance with an example zero-knowledge datamanagement system herein;

FIG. 15 illustrates an example of an attestation service environment inaccordance with an example zero-knowledge data management system herein;

FIG. 16 illustrates an example communication exchange between thedevices of the attestation service environment in accordance with anexample zero-knowledge data management system herein;

FIGS. 17A-17B illustrate examples of attestation service operation andattestation tracking in accordance with an example zero-knowledge datamanagement system herein;

FIG. 18 illustrates an example of attestation services where multiplesets of source data are associated together in accordance with anexample zero-knowledge data management system herein;

FIG. 19 illustrates an alternative embodiment for signed attestationcertificates, particularly being managed by the source device inaccordance with an example zero-knowledge data management system herein;

FIGS. 20A-20E illustrate examples of encrypting and decryptingcombinations for attestation-server-based key rotations in accordancewith an example zero-knowledge data management system herein;

FIG. 21A illustrates an example implementation of an examplezero-knowledge data management system herein;

FIG. 21B illustrates a specific example of an intermediate reportingservice according to an example zero-knowledge data management systemherein;

FIGS. 22A-22C illustrate an example simplified procedure forzero-knowledge data management in accordance with one or moreembodiments described herein, particularly from the perspective of astorage server;

FIGS. 23A-23B illustrate another example simplified procedure forzero-knowledge data management in accordance with one or moreembodiments described herein, particularly from the perspective of asource device;

FIG. 24 illustrates an alternative example of a concealed informationsystem in accordance with one or more embodiments described herein, suchas a zero-knowledge data management system, particularly where there aremultiple devices that may access concealed information;

FIGS. 25A-25C illustrate an example of using multiple devices to accessconcealed information in accordance with one or more embodimentsdescribed herein;

FIG. 26 illustrates an example simplified procedure for storingencrypted data for access by a trusted device described herein; and

FIG. 27 illustrates an example simplified procedure for accessingencrypted information with a trusted device described herein.

DESCRIPTION OF EXAMPLE EMBODIMENTS

A computer network is a distributed collection of nodes (e.g.,transmitters, receivers, transceivers, etc.) interconnected bycommunication links and segments for transporting signals or databetween the nodes, such as personal computers, workstations, mobiledevices, servers, routers, or other devices. Many types of computernetworks are available, including, but not limited to, local areanetworks (LANs), wide area networks (WANs), cellular networks, broadbandnetworks, infrastructure or backhaul networks, and many others.

FIG. 1 illustrates an example, and simplified, computer network 100. Asshown, computer network 100 may contain various devices communicatingover links 110 and an internetwork 115, such as end devices 120, servers130, databases 140 (which may be part of servers 130 or in communicationwith and under the control of servers 130), and other devices as will beappreciated by those skilled in the art. Data transmissions 150 (e.g.,packets, frames, messages, transmission signals, etc.) may be exchangedamong the nodes/devices of the computer network 100 using predefinedcommunication protocols where appropriate over links 110. In thiscontext, a protocol consists of a set of rules defining how the nodesinteract with each other.

Notably, the computer network 100 may comprise various individualnetworks intercommunicating with each other, such as LANs, WANs,cellular/LTE networks, and so on, and may include any number of wired orwireless links between the devices, accordingly. Note also that whilelinks 110 are shown generically interconnecting with the internetwork115, any number of intermediate devices (e.g., routers, switches,firewalls, etc.) may actually make up the composition of the network 100and internetwork 115, and the view shown herein is merely a simplifiedillustration.

End devices 120 may comprise different types of devices, such as, e.g.,personal computers, desktop computers, laptop computers, mobile devices,tablets, smartphones, wearable electronic devices (e.g., smart watches),smart televisions, set-top devices for televisions, workstations, smartvehicles, terminals, kiosks, automated teller machines (ATMs),applications running on such devices, and so on, often interfaces withhuman users, though not necessarily. For instance, end devices 120 mayalso comprise sensors, actuators, drones, automated vehicles, other“Internet of Things” (IoT) devices, and so on, configured generally toobtain, process, or act on data.

Servers 130 and/or databases 140 may comprise singular servers and/ordatabases, server and/or database farms, cloud-based server and/ordatabase services, network attached storage (SAN), and any other type orconfiguration of computing devices that provides computing and/orstorage services as will be appreciated by those skilled in the art.Servers 130 and/or databases 140 may be centralized (i.e., processingand/or storage occurring on a single device or within a single locationof devices) or distributed/decentralized (i.e., processing and/orstorage occurring across multiple devices or across a plurality oflocations). Notably, for example, servers 130 and/or databased 140 maybe deployed on the premises of an enterprise or may be cloud-based, suchas the Amazon® “Simple Storage Service” (S3).

FIG. 2 is a simplified schematic block diagram of an example computingdevice 200 that may be used with one or more embodiments describedherein (e.g., end device 120, sever 130, database 140, etc.).Illustratively, device 200 may generally include one or morecommunication interfaces 210, one or more processors 220, and a memory240 interconnected by a system bus 250 or other dedicated circuitry, andis powered by a power supply system 260. Additionally, the device 200,where required, may comprise one or more user interfaces 230 configuredto solicit and receive user input (input/output or “I/O” components,such as displays, keyboards, touchscreens, and so on).

The communication interfaces 210 include the mechanical, electrical, andsignaling circuitry for communicating data over wired and/or wirelesslinks of a communication network.

The memory 240 includes a plurality of storage locations that areaddressable by the processor(s) 220 for storing software programs anddata structures associated with the embodiments described herein. Theprocessor(s) 220 may comprise necessary elements or logic adapted toexecute the software programs and manipulate the data structures 245(e.g., encryption and decryption keys, such as public-private key pairs,as described below). An operating system 242, portions of which aretypically resident in memory 240 and executed by the processor(s) 220,functionally organizes the device by, among other things, invokingoperations in support of software processors and/or services executingon the device. Illustratively, these software processes and/or servicesmay include one or more functional processes 246 (e.g., specific tofunctionality of the device), an example “zero-knowledge datamanagement” process 248 that is configured to perform the operationsdescribed herein.

It will be apparent to those skilled in the art that other processor andmemory types, including various computer-readable media, may be used tostore and execute program instructions pertaining to the techniquesdescribed herein. Also, while the description illustrates variousprocesses, it is expressly contemplated that various processes may beembodied as modules configured to operate in accordance with thetechniques herein (e.g., according to the functionality of a similarprocess). Further, while processes may be shown and/or describedseparately, those skilled in the art will appreciate that processes maybe routines or modules within other processes.

As mentioned above, information privacy and security is important tocomputer technology. With the proliferation of hacking incidents againststored information by compromised passwords and/or encryptiontechniques, whether directed to locally managed servers or cloud-baseddata storage, attack vulnerability has been addressed in many ways toprevent or at least detect unsanctioned access to the data. Still, tothis day, such efforts have been unable to keep up with the dedicationof ill-willed individuals to overcome the many firewall configurations,the multiple layers of security, the authorized access management, andthe overall ever-changing data security landscape set forth by theadministrators tasked with protecting the stored and communicated data.

As also mentioned above, although such information may include generallyharmless data (e.g., online profiling/habit data), or at least data thatis already public but perhaps more of a nuisance if disseminated morewidely than intended (e.g., email addresses used for spamming users orfor phishing campaigns), some information may be particularly moreproblematic (including illegal in certain instances) if acquired by animmoral individual. For instance, personally identifying information(PII), financial information, business-sensitive or legally protectedinformation, and other particularly restricted or classified informationcan be especially worthwhile for hackers to obtain, especially in bulk(e.g., information from many hundreds of thousands of users at a time).As such, though certain legitimate companies may be strongly based onstoring and accessing this data (e.g., social media websites, marketingand advertising services, online gaming, etc.), other companies wouldprefer to not be responsible for maintaining the secrecy of the data(e.g., e-commerce companies, retail companies that currently storeinformation on millions of shoppers). Still, regardless of whether thedata is more or less detrimental if in the wrong hands, control over whohas access to this data has conventionally been completely out of theuser's control.

One specific example of secure data that may be stored is identity data,such as “know your customer” data, particularly for financialinstitutions (e.g., banks). Know your customer (or client) (KYC)generally refers to the process of verifying a user's identity (e.g., aperson or entity), though the term may be used specifically to refer tothe bank regulations and anti-money laundering (AML) regulations whichgovern these activities. For instance, the United States Bank SecrecyAct (BSA), also known as the Currency and Foreign Transactions ReportingAct, requires financial institutions (e.g., banks, credit cardcompanies, life insurers, money service businesses, and broker-dealersin securities) to report certain transactions to the United StatesDepartment of the Treasury. In particular, a currency transaction report(CTR) is a report that U.S. financial institutions are required to filewith the Financial Crimes Enforcement Network (FinCEN) for each deposit,withdrawal, exchange of currency, or other payment or transfer, by,through, or to the financial institution which involves a transaction incurrency of more than $10,000, identifying the individuals (e.g., name,social security number, etc.) or entities involved in the transaction aswell as the source of the cash.

The BSA is sometimes referred to as an anti-money laundering (AML) law.Primary objectives of KYC guidelines are thus to prevent banks or onlinebusinesses from being used, intentionally or unintentionally, bycriminal elements for money laundering activities, although relatedprocedures also enable banks to better understand their customers andtheir financial dealings (e.g., for customer acceptance policies,customer identification, monitoring of transactions, and riskmanagement). In other words, the BSA requires financial institutions toengage in customer due diligence (e.g., KYC), which includes obtainingsatisfactory identification to give assurance that the account is in thecustomer's true name, and having an understanding of the expected natureand source of the money that flows through the customer's accounts. TheKYC information must accordingly be stored by the financialinstitutions, ready for use when reporting suspicious activities.

Given the type and amount of information obtained, financialinstitutions, in particular, are therefore highly regulated with regardto their data security controls. Additionally, certain cryptocurrencies,though generally often priding themselves on the anonymity of theirusers' transactions or identities, will likely face the same regulationsas traditional financial institutions, given that their anonymity can be(and unfortunately is) abused for used illegal and illicit behavior(e.g., drugs, human trafficking, money laundering, funding terrorism,and so on). Any shift in governmental attention, however, could resultin many of these cryptocurrencies being fined, criminally prosecuted,and/or shut down entirely, possibly devaluing the correspondingcryptocurrency to worthlessness, leaving many legitimate users andinvestors with little more than a lesson learned. As such, it isexpected that many cryptocurrency companies will begrudgingly begin toobtain KYC data as well over time.

Due to of the wide spectrum of types of data communicated and stored,from the benign to the damaging, as well as the plethora of reasons tostore and communicate the data, from commercial benefit to forcedregulation, there is a correspondingly large array of attitudes andopinions regarding the storage of such data. On the one hand, theentities that operate (in at least some capacity) on the data want tohave access to the data, and are thus willing to store the data, albeitat the (hopefully mitigated) risk of the data being hacked. On the otherhand, entities that are required to collect and store the data but thatdo not need the data in order to operate (e.g., banks do not need morethan an account number to conduct transactions, but are nonethelessrequired to have KYC data ready for reporting) would often rather not beresponsible for the storage and/or management of the hackable data. Inboth hands, however, that is to say, regardless of whether an entitywants access to the data or not, the threat of the data beingmisappropriated is a constant fear held by nearly all administratorsresponsible for data management.

Various measures have been taken to protect data over the years,including, most notably, encrypting the data. In cryptography,encryption is the process of encoding a message or information in such away that only authorized parties should be able to access it, whilethose who are not authorized cannot. In particular, encrypting dataprevents content from being intelligible to a would-be interceptor byapplying an encryption algorithm (e.g., a cipher) to the readable or“plaintext” data (stored information or transmitted message) in order togenerate “ciphertext” (encrypted data) that can be read only ifdecrypted. An authorized recipient can then decrypt the data using adecryption algorithm (e.g., a key provided by the originator torecipients but not to unauthorized users).

There are generally two types of data encryption techniques: symmetricand asymmetric. In symmetric schemes (also referred to as symmetric-keyor private-key), the encryption and decryption keys are the same.Communicating parties must thus have the same key in order to achievesecure communication. Data storage servers using symmetric schemes alsostore data encrypted with the same key that would be used for decryptingthe data. Symmetric schemes are thus based on all necessary partieshaving knowledge of the same key, which puts all of the data at risk ofbeing accessed by unauthorized parties with access to the single key orthat can break the key.

Alternatively, asymmetric encryption schemes (also referred to asasymmetric-key or public-key), which are cryptographic systems that usespairs of keys, the intended recipient's encryption key is published(e.g., disseminated widely or else obtained as-needed) for anyone to useand encrypt data and messages. However, only the receiver has access toa corresponding decryption key that enables data and messages to beread.

Since in an asymmetric key encryption scheme, anyone can encrypt data ormessages using the public key, security depends on the secrecy of therecipient's paired private key.

As an example, assume first of all, for ease of discussion, thatasymmetric encryption is much like multiplication in terms of itscommutative and associative properties, meaning that the order ofapplying an encryption or decryption key to the data (an “encryptingcombination” generally, herein) does not matter. This may be representedmathematically as:

A=(B*C)*D=C*B*D=(C*D)*B, etc.  Eq. 1.

Asymmetric encryption may thus be represented generally as follows(where the encryption, decryption, or generally “encrypting combination”where keys are applied to raw or encrypted data, is represented in theequation as a multiplication or “*”):

Raw Data*Public Key=>Cypher Data  Eq. 2a;

As mentioned, to decrypt data encrypted by a public key, a private keyis used, since:

Public Key*Private Key=>1(decryption)  Eq. 2b.

Therefore, the decryption of the cypher data would be represented asfollows:

$\begin{matrix}{{{Cypher}{Data}*{Private}{Key}} = {{\left( {{Raw}{Data}*{Public}{Key}} \right)*{Private}{Key}} = {{{Raw}{Data}*\left( {{Public}{Key}*{Private}{Key}} \right)} = {{{Raw}{Data}*(1)} = {> {{Raw}{{Data}.}}}}}}} & {{{Eq}.2}c}\end{matrix}$

Notably, it is, in principle, possible to decrypt data or a messagewithout possessing the key, or to steal or otherwise reverse engineerthe key. However, for a well-designed encryption scheme, considerablecomputational resources and skills are required. (The strength of acryptography system relies on the computational effort or “work factor”required to find the decryption key, e.g., to find the private key fromits paired public key. Notably, simply “guessing” the decryption key maytake thousands of years using today's computing power, thus renderingthe encryption practically unbreakable.) To understand the problemassociated with using standard encryption techniques in order to securedata transmission and storage, FIG. 3 illustrates an example blockdiagram of a typical storage server environment 300, where a sourcedevice 310 is trying to send source data 315 to a storage server 320,which would then send the data to a recipient device 330, as describedbelow. As an illustrative example, the source device 310 may be a userdevice or application, storage server 320 may be a financialinstitution, and the recipient device 330 may be a regulatory complianceagency device (e.g., FinCEN). (Note that in this example, it can also betempting for the financial institution to shift its responsibility ofdata security by employing an independent server as storage server 320rather than using the financial institution's own servers. However,while this may protect the financial institution against liability, theindependent servers would suffer the same issues mentioned below).

For traditionally secure communication of data, the source device 310(which has its own public and private keys 311/312) would know and usethe public key 321 of the storage server 320, and encrypts source data315 (“Src Data”) with the storage server's public key (“Srvr Pub”) 321as:

Src Data (315)*Srvr Pub (321)=>Cypher Data 1 (317)  Eq. 3a.

The storage server 320 receives the cypher data 317 (source-encryptedsource data), and can either store the encrypted data without decryptingit, or may decrypt it back to its raw source data format 315 using theprivate key 322 of the storage server (“Srvr Pri”):

$\begin{matrix}{{{Cypher}{Da}{ta}(317)*{Srvr}{{Pro}(322)}} = {{\left( {{Src}{Data}(315)*{Srvr}{Pub}(321)} \right)*{Srvr}{{Pri}(322)}} = {{{Src}{Data}(315)*\left( {{Srvr}{Pub}(321)*{Srvr}{Pri}(322)} \right)} = {{{Src}{Data}(315)*(1)} = {> {{Src}{Data}{(315).}}}}}}} & {{{Eq}.3}b}\end{matrix}$

That is, the storage server's private key 322 applied to the storageserver's public key 321 decrypts the encrypted source data, as describedabove in Eqs. 2a-2c.

When the storage server 320 is tasked with relaying the source data 315to a chosen recipient device 330 (e.g., when the bank is required tofile a currency transaction report (CTR) with FinCEN, which includes KYCdata), then the storage server, if needed, would now decrypt the cypherdata 317, and re-encrypts the raw source data 315 using the public key331 of the ultimate recipient device 330 (“Rcpt Pub”):

Src Data (315)*Rcpt Pub (331)=>Cypher Data 2 (327)  Eq. 4a.

Accordingly, the recipient device 330 can then obtain the originalsource data 315 by using their private key 332 (“Rcpt Pri”):

$\begin{matrix}{{{Cypher}{Da}{ta}2(327)*{Rcpt}{Pri}(332)} = {{\left( {{Src}{Data}(315)*{Rcpt}{Pub}(331)} \right)*{Rcpt}{{Pri}(332)}} = {{{Src}{Data}(315)*\left( {{Rcpt}{Pub}(331)*{Rcpt}{Pri}(332)} \right)} = {{{Src}{Data}(315)*(1)} = {> {{Src}{Data}{(315).}}}}}}} & {{{Eq}.4}b}\end{matrix}$

As can be seen, the security of the communication and storage of thesource data 315 is dependent on a number of vulnerabilities, in orderbelow generally based on increasingly negative impact:

-   -   whether a source device 310 can be hacked, granting access to        the particular source data for that source device;    -   whether a recipient device 330 can be hacked, granting access to        the any raw source data stored at that recipient device;    -   whether a recipient's private key 332 can be hacked/broken,        granting access to all eavesdropped communications of source        data from the storage server (or anywhere) to this particular        recipient device, and/or granting access to all source data        stored in an encrypted fashion (327) at the particular        recipient;    -   whether the storage server 320 stores the raw source data 315        and can be hacked, granting access to ALL raw source data stored        at the storage server from ALL source devices; and    -   whether the storage server's private key 322 can be        hacked/broken, granting access to ALL eavesdropped        communications of source data from ALL source devices to the        storage server, AND/OR granting access to ALL source data stored        in an encrypted fashion (317) at the storage server from ALL        source devices (i.e., a malicious hacker gains access/control to        the storage server 320, enabling them to steal both the        encrypted data 317 and the private key 322, thus giving them        access to the raw stored information 315). Note that the risk        here for compromising the data security is not limited to        outside attacks, but also stems from the fact that employees of        entity who owns the storage server 320 (e.g., a bank employee)        may steal the private key 322 or may simply just gain access to        confidential information 315 that is stored on the storage        server 320.

In other words, traditional encryption techniques are only as good asthe security of the devices, and the strength of the encryption. For thestorage server in particular, whether the data collecting entity itself(e.g., banks, retail, social networks, etc.) or an employed independentstorage server, the chance of having a security breach that results inthe unauthorized visibility of all raw data or all data using thebroken/stolen private key is daunting and ultimately likely withoutconstantly trying to stay one step ahead of hackers attempting to breakinto the storage system.

Note that the source device 310 could also bypass the storage server'sencryption by encrypting the source data 315 directly with the publickey 331 of the recipient device 330, such as where there is only oneintended recipient device for the source data (and the storage server320 is merely an intermediary storage location). However, in thissituation, though the storage server 320 would be unable to view thesource data (without the recipient's private key 332), generallyalleviating its liability for the security of the data, the storageserver would be required to store a differently encrypted version of thesource data 315 for every possible recipient device, greatly increasingthe amount of redundant data stored at the storage server (especiallywhere the data comprises vast amounts of information or large/numerousfiles). Furthermore, institutes such as banks are often required toensure that the KYC information entered by a user is correct. However,if the user were to encrypt the KYC information directly with the publickey of the intended recipient device (e.g., the government), then thebank (or enterprise acting on behalf of the bank) would not have thenecessary access to the KYC information, and would thus be incapable ofverifying the information.

Additionally, companies such as Facebook®, Google®, and others useinformation about users to the benefit of their organization withoutsharing with the users the profits made by using the users' privateinformation. That is, there is currently no framework that allows usersto control who has access to their private information and to share inthe benefits of allowing others to utilize this information.

——Zero-Knowledge Data Management——

With the daily headlines of massive breaches and abuses of consumerdata, such as those generally mentioned above (and, as more specificexamples, those that may be found at https://en.wikipedia.org/wiki/Listof data breaches), computer technology is at the birth of a much-neededmovement to change how businesses and consumers share data and identifyone another. Yet businesses are faced with a paradoxical challenge—howto protect consumer data (e.g., from data leakage), or outright get ridof the consumer data, without sacrificing how the businesses market,interact, and transact with the customers, or how they generate reportsfor third-parties (e.g., government regulatory agencies). That is, theup-trending of data breaches raises questions how can data be securelycommunicated and stored without subjecting the intermediary devices,such as storage servers (or the financial institutions or other datacollectors themselves), to hacking and other malicious attacks. Also,consumers have been demanding greater control over who has access totheir secure information, but administrators have been unable toadequately address this demand without over-utilizing and wastingstorage and/or communication resources.

The techniques herein, therefore, provide for a “zero-knowledge” datamanagement network that addresses these concerns, and more. Inparticular, according to one or more embodiments described herein, usersare able to share verifiable proof of data and/or a limitless list ofdetails about themselves (identify information), and businesses are ableto request, consume, and act on the data, providing a hyper-personalizedexperience—all without a data storage server or those businesses everseeing or having access to the raw sensitive information. That is, theembodiments herein are directed to a decentralized network for trust,identity, information verification, privacy, and personalization thatreinvents secure data storage and digital identities, whereserver-stored data is viewable only by the intended recipients, whichmay even be selected after storage of the data. Additional provisionsfor secure data attestation for information verification and secondarydata protection layers are also described herein.

Specifically, according to one or more embodiments of the techniquesherein as described in greater detail below, a storage server obtainssource data from a source device, where no device other than the sourcedevice is able to read the source data. The storage server may alsoobtain a request to share the source data with a particular recipientdevice, and also obtains, from the source device, a conversion keyspecific to the particular recipient device. As such, the storage servercan convert the source data into a format readable only by theparticular recipient device based on the conversion key, and sends thesource data in the format readable only by the particular recipientdevice to the particular recipient device, accordingly.

In particular, in one embodiment, a storage server may obtainsource-encrypted source data from a source device, where thesource-encrypted source data comprises source data encrypted by thesource device with a source encryption key of the source device (e.g., asource public key). The storage server stores the data, and is notablyunable to decrypt the source-encrypted source data. The storage servermay also obtain a recipient-based rekeying key from the source device,the recipient-based rekeying key established through an encryptingcombination of a source decryption key of the source device (e.g., asource private key) and a recipient public key of a particular recipientdevice. In response to receiving a request to share the source data withthe particular recipient device, the storage server may then re-encryptthe source-encrypted source data with the recipient-based rekeying key,the re-encrypting resulting in recipient-based encrypted source datathat is the source data encrypted with the recipient public key of theparticular recipient device. Note still that the storage server is alsounable to decrypt the recipient-based encrypted source data. The storageserver then sends the recipient-based encrypted source data to theparticular recipient device to cause (or otherwise enable) theparticular recipient device (and only the particular recipient device)to decrypt the recipient-based encrypted source data using a recipientprivate key of the particular recipient device to obtain the sourcedata, accordingly. (Further embodiments of the present disclosure arealso described in greater detail below.)

Illustratively, the techniques described herein may be performed byhardware, software, and/or firmware, such as in accordance with the“zero-knowledge data management” process 248, which may include computerexecutable instructions executed by a processor 220 (of a particularcorrespondingly operative device 200) to perform functions relating tothe techniques described herein, e.g., in conjunction with other deviceswhich may have a correspondingly configured zero-knowledge datamanagement process 248 depending upon the functionality of the device,as described below (e.g., a source device, a storage server, a recipientdevice, a controller device, an attestation service, and so on).

Operationally, the techniques herein are based on a collection ofdevices participating in a data storage system (e.g., a zero-knowledgedata management network). With reference generally to the simplifieddata storage system 400 in FIG. 4 , a source device 410 communicateswith a storage server 420 and a recipient device 430, similar to asshown in FIG. 3 above. System 400 of FIG. 4 also specifically includes a“controller device” 440, which may be any device (e.g., a “controllerdevice”) that is involved in some way in an interaction that isprimarily between the source device 410, storage server 420, andrecipient device 430. That is, controller device 440 is a device thatmay be involved in the overall transaction of the raw data describedherein (e.g., dictating the secure data collection by source devicesand/or initiating secure data exchanges, and so on), but according tothe techniques herein, is not privy to accessing the raw data. In oneexample, the controller device 440 may be the bank in the illustrationabove, with the source device 410 being the user's device and therecipient device 430 being the regulatory servers configured to receivereports on large financial transactions. Any other arrangement andpurpose of the source, server, recipient, and controller devices may beconfigured and used herein, and the financial institution and reportingexample herein is merely for illustrative discussion herein.

Source device 410 may generally comprise any type of data collectiondevice, such as user devices, sensors, etc., that is configured tocollect or otherwise obtain source data 415. For instance, in oneembodiment, source device 410 may be established as an application or awebsite configured to collect the source data, such as under thedirection of the storage server 420, by the controller device 440, or incertain circumstances by the recipient device 430. For instance, thesource device 410 may collect information on its own (e.g., theapplication instructs a user to input identity information to share withany number of recipients as directed and to satisfy the requirements ofany number of third-party and/or controller devices), or else mayspecifically receive instructions from a controller device 440 or server420 to collect the source data (e.g., the bank requiring the sourcedevice to collect certain data from a user, or the storage serverrequesting the same information generally for a plurality of third-partyand/or controller devices). Source data 415 may comprise personally anycollected information, such as website cookies, search terms, personallyidentifying information (PII), names, addresses, phone numbers, creditcard numbers, bank account numbers, usernames, passwords, pins, socialsecurity numbers, and many other pieces of information, including files,documents, images, program code, sensed data, and so on.

Storage server 420 may generally comprise one or more server devices,databases, and so on. Various communication and storage protocols may beused by the storage server, such as the File Transfer Protocol (FTP),secure FTP (SFTP), redundant array of inexpensive (or independent) disks(RAID), and so on. Also, recipient device(s) 430 may generally be anydevice (or set of devices) that are configured to receive and processthe source data 415 as described herein. For example, recipient devicesmay be such devices as, e.g., a governmental device, a regulatorycompliance device, a financial institution device, a retail companydevice, an auditing system device, a medical system device, a userdevice, and others.

Notably, each device in the system 400 may have its own public/privatekey pair (or other encryption/decryption key pair for asymmetricencryption, accordingly). As shown, source device 410 thus has a sourcepublic key 411 and source private key 412, server 420 has a storageserver public key 421 and server private key 422, and recipient device430 has a recipient public key 431 and recipient private key 432.(Controller device 440 may also have its own public/private key pair,but since the techniques herein do not require them other than standardcommunication encryption, they are not specifically shown herein forsimplicity.)

FIG. 5 , discussed while also still referencing FIG. 4 , illustrates anexample communication exchange 500 between the devices of system 400above according to one or more embodiments of the techniques herein.(Notably, the order of certain steps may be rearranged or evencontemporaneous, and the example shown herein is not meant to belimiting to the scope of the present disclosure.)

According to one or more embodiments of the techniques herein, thesource device 410 obtains the source data 415, such as through a generalapplication to collect data for sharing across a plurality ofrecipients/services (e.g., an app designed to collect then shareinformation with any participating and authorized devices), or at thedirection of some other device or organization, such as a controllerdevice 440 (e.g., a bank) or the intended recipient device 430 (e.g., agovernment institution). Once the source device has the data, the sourcedata may then be encrypted with a source encryption key 411 (e.g., apublic key) of the source device to form source-encrypted source data417 (“Src-Encrypt Src Data”) as shown below, and as shown in FIG. 6A:

Src Data (415)*Src Pub (411)=>Src-Encrypt Src Data (417)  Eq. 5.

Note that unlike traditional encryption, where the source device wouldnormally encrypt the data with recipient encryption keys (e.g., publickeys), the source device's use of its own encryption key (e.g., itspublic key, herein) ensures that only the source device can decrypt thesource-encrypted source data 417 with its decryption key 412 (e.g., itsprivate key, herein), or else can otherwise control the decryption asdescribed herein (e.g., through re-encryption techniques describedbelow). That is, no other device, including the storage server 420 (orrecipient device 430 or controller device 440), can decrypt thesource-encrypted source data 417. Note that in the traditional sense, adevice's decryption key is its private key, so only it, as a receiver,can decrypt encrypted data. However, as used herein in the preferredembodiment, since the source device has changed the role of its keys,the use of the term “encryption key” corresponds to the key used by thesource device herein to encrypt the source-encrypted source data (e.g.,the public key), while “decryption key” corresponds herein to the pairedkey used by the source device to decrypt or, as described below,re-encrypt the source-encrypted source data. (Note also that in thissense, any device with access/knowledge of the source device'spublic/encryption key can generate source-encrypted source data, thoughonly the source device itself would then have control over thedecryption of that source-encrypted source data, as described herein.This may be useful, for instance, in certain embodiments where anothertrusted device generates and stores data on behalf of the source device,and the source device controls further access to this data,accordingly.)

Referring still to FIGS. 4-5 , after the encryption takes place, thesource device sends the source-encrypted source data 417 to the storageserver 420. Notably, even though the storage server obtains and storesthe source-encrypted source data, it is completely unable to decrypt it(that is, without having the source device's private/decryption key412). Note also that the source device need not continue to store theraw data, and may delete (or generally not store) any source data onceit is encrypted into the source-encrypted source data for even furthersecurity against hacking (e.g., locally decrypting it if needed again inthe future using its own decryption key, whether for access or editing).

According to the techniques herein, the source device 410 alsoestablishes a “recipient-based rekeying key” 418 through an encryptingcombination of a source decryption key 412 (e.g., private key) of thesource device and a recipient public key 431 of a particular recipientdevice 430. In particular, and as shown in FIG. 6B, the source deviceuses its decryption key 412 (“Src Pri”) to encrypt the recipient publickey 431 (“Rcpt Pub”) (though as mentioned above, the same result wouldessentially occur by encrypting the Src Pri with the Rcpt Pub), andcreates the recipient-based rekeying key 418 (“Rcpt-Bsd Rekey Key”),accordingly:

Src Pri (412)*Rcpt Pub (431)=>Rcpt-Bsd Rekey Key (418)  Eq. 6.

Notably, in one embodiment, the source device 410 receives the recipientpublic key 431 by receiving it from the recipient device, such as frompublic broadcasting of public keys or requesting certain keys forparticipating recipient devices (e.g., governments, retailestablishments, reward programs, financial institutions, socialnetworks, etc.). In addition to the recipient devices informing thesource device of their recipient public key, techniques herein alsospecifically contemplate the scenario where the public key of aparticular recipient is obtained in response to a request to share thesource data with the particular recipient (as described below). Forexample, a controller device or a particular recipient device may send arequest to the storage server 420 requesting that the source data besent to the particular recipient device 430. At this time, therefore(i.e., where the request is received prior to obtaining therecipient-based rekeying key), the storage server 420 may obtain, if notalready stored, the public key 431 of the particular recipient 430, andshares it with the source device, to thus cause the source device toestablish and send the recipient-based rekeying key 418 to the storageserver.

The source device 410 then sends the recipient-based rekeying key 418 tothe storage server 420, which, notably, still does not allow the storageserver to decrypt the source-encrypted source data 417. That is, therekeying key is only useful by the storage server to re-encrypt thesource-encrypted source data 417 in a way that allows the particularrecipient device, correspond to that recipient-based rekeying key 418,to decrypt the data, as described below. Additionally, since therecipient-based rekeying key 418 is a combination of the source device'sprivate key (or other decryption key) and the recipient device's publickey, the only data transformation that the storage server 420 (e.g., ifhacked), or any other device for that matter, could perform on therecipient-based rekeying key 418 is based on knowing the source device'spublic key 411, which as shown in Eq. 6b below, merely would result inthe publicly known public key of the recipient:

$\begin{matrix}{{{Rcpt} - {Bsd}{Rekey}{Key}(418)*{Src}{{Pub}(411)}} = {{\left( {{Src}{Pri}(412)*{Rcpt}{Pub}(431)} \right)*{Src}{Pub}(411)} = \left( {{{Src}{Pri}(412)*\left( {{Src}{Pub}(411)} \right)*{Rcpt}{Pub}(431)} = {{(1)*{Rcpt}{Pub}(431)} = {> {{Rcpt}{Pub}{(431).}}}}} \right.}} & {{{Eq}.6}b}\end{matrix}$

(Note that there is also minimal risk for the particular recipientdevice 430 to obtain the source device's private key 412 using therecipient device's private key, since the particular recipient devicesshould be trusted devices, but still, care should be taken by thestorage server 420 to prevent access by the particular recipient deviceto the recipient-based rekeying key 418. Though typically the recipientdevice would not have access to its corresponding rekeying key, in orderto maximize security to prevent a hacked recipient device from gainingthat access, greater details with regard to preventing this access areprovided in the discussion further below.)

The source device 410 may send the recipient-based rekeying key 418 tothe storage server after sending the source-encrypted source data 417,such as when the source data is sent at the direction of the sourcedevice, and then requests later dictate the creation of particularrekeying keys. On the other hand, the source device may also send therecipient-based rekeying key 418 to the storage server contemporaneouslywith sending the source-encrypted source data 417, such as where thesource device dictates the sharing of the data with particularrecipients, or else where the data is collected in response to therequest to share the data with the recipient or in anticipation ofreceiving a request to share the data, such as anticipating a requestfrom the government to share the data, or in anticipation of a requestfrom a bank to share specific information with the government.

As mentioned above, the storage server 420 may receive a request 550 toshare the source data 415 with the particular recipient device 430.Various reasons may cause the request to be sent to (or to be internallydetermined by the storage server). In particular, the request 550 toshare the source data with the particular recipient device may bereceived from the source device 410 (e.g., on its own volition or inresponse to a request first received by another device), the recipientdevice 430 (e.g., to specifically request the data itself, rather thanbeing pushed the data from the storage server, such as based on otherdevices' requests or server trigger conditions), or an authorizedcontroller device 440 (e.g., based on detected events, generation ofcorresponding reports, or other reasons, such as auditing, marketingcampaigns, data transfer control, and so on). Note that a controllerdevice herein is unable to decrypt the source-encrypted source data (orthe source data encrypted with the recipient public key, describedbelow), and thus requests sharing of the data without ever having accessto the data.

In addition to triggers being based on financial transactions asmentioned in the example above, including regulated transfers of largesums and making purchases at retail stores (e.g., online shopping),other triggers may include social media requests, customer loyaltyprogram triggers, user-directed requests to share the data,security-based policies for sharing the data (e.g., staticallyconfigured or based on behavioral analytics), and so on. Triggers forrequests may also be unrelated to the source data (e.g., periodicreporting, auditing, based on other data or other factors, based onother devices entirely, and so on).

Note that in still another embodiment, the request may be aself-determined request by the storage server 420 in response to one ormore triggers or policies (that is, triggering, by the storage server, aself-determined request in response to one or more policies at thestorage server, e.g., static or based on behavioral analytics). In otherwords, the storage server itself may be configured to determine when(and whether) to send the source data to a particular recipient device.(Note that since the storage server 420 does not have access to the rawsource data 415, any triggers by the storage server to share the sourcedata may generally be based on factors unrelated to the actual dataitself, such as a size of the data, a number of times or frequency atwhich the data is updated, a length of time since the data was stored, alength of time since the last sharing of the data, a policy to alwayssend a particular source device's data to a particular recipient device,and so on.)

As an example of a request to share the source data, assume that thecontroller device 440 is configured to perform a transaction with thesource device, such as a financial transaction, and may detect a triggerto share the source data with the particular recipient device based onthe transaction. Though one example noted above is to generate acurrency transaction report (CTR) when a transaction involves more than$10,000 in cash is processed, other triggers such as user-initiated orsystem-based triggers (e.g., if the bank employee or system believes atransaction to be suspicious or fraudulent, commonly called a SuspiciousActivity Referral (SAR)). For instance, if a customer revises an initialCTR-triggering request to deposit or withdraw $9,999, or multipletransactions just under the $10,000 threshold, this “structuring”attempt may be subjected to SAR-based reporting as well. Still othertriggers may be based on behavioral anomalies such as any sudden andsubstantial increase in funds, a large withdrawal, or moving money to abank secrecy jurisdiction. In response to any of these and othertriggers, therefore, the controller device 440, in particular, may sendor otherwise initiate a request to share the source data with aregulating authority recipient device, accordingly.

In response to the request 550 (or internal triggering), the storageserver 420 may request the recipient-based rekeying key 418 if itdoesn't already have it (and may share the recipient device's public key431 if the source device doesn't already have that, too). Regardless,once the storage server has the recipient-based rekeying key 418 fromthe source device (which, notably, may have been receivedcontemporaneously with the request 550 or prior to obtaining therequest), and also the source-encrypted source data 417 from the sourcedevice (which, notably, may have been received contemporaneously withthe rekeying key 418, thus also possibly contemporaneously with therequest or prior to obtaining the request), the storage server may,according to the techniques herein, re-encrypt the source-encryptedsource data 417 with the recipient-based rekeying key 418. Inparticular, the re-encrypting results in the source data 415 beingencrypted with the recipient public key 431 of the particular recipientdevice 430, i.e., “recipient-based encrypted source data” 427 (“Rcpt-BsdEncrypt Src Data”), as shown below in Eq. 7 and in FIG. 6C:

$\begin{matrix}{{{Src} - {Encrypt}{Src}{Data}(417)*{Rcpt} - {Bsd}{Rekey}{Key}(418)} = {{\left( {{Src}{Data}(415)*{Src}{Pub}(411)} \right)*\left( {{Src}{Pri}(412)*{Rcpt}{Pub}(431)} \right)} = {{{Src}{Data}(415)*\left( {{Src}{Pub}(411)*{Src}{Pri}(412)} \right)*{Rcpt}{Pub}(431)} = {{{Src}{Data}(415)*(1)*{Rcpt}{Pub}(431)} = {{{Src}{Data}(415)*{Rcpt}{Pub}(431)} = {> {{Rcpt} - {Bsd}{Encrypt}{Src}{Data}{(427).}}}}}}}} & {{Eq}.7}\end{matrix}$

Note that the storage server 420 is still unable to decrypt the sourcedata encrypted with the recipient public key (i.e., recipient-basedencrypted source data 427), since only the particular recipient devicecan do that with its private key 432 (described below). No other device,including the controller device, other recipient devices, or, in fact,the source device, can decrypt the recipient-based encrypted source data427, so even if a hacker somehow obtained the recipient-based encryptedsource data 427, they would have no way to open/access the raw sourcedata 415, or any other useful information.

At the direction of the request 550 or based on any other triggersdescribed herein, the storage server may now send the recipient-basedencrypted source data 427 to the particular recipient device 430. Uponreceipt, this causes or otherwise enables the particular recipientdevice 430 to decrypt the recipient-based encrypted source data 427using a recipient private key 432 of the particular recipient device tothereby obtain the original/raw source data 415. This is shown below,and with reference to FIG. 6D:

$\begin{matrix}{{{Rcpt} - {Bsd}{Encrypt}{Src}{Data}(427)*{Rcpt}{Pri}(432)} = {{\left( {{Src}{Data}(415)*{Rcpt}{Pub}(431)} \right)*{Rcpt}{Pri}(432)} = {{{Src}{Data}(415)*\left( {{Rcpt}{Pub}(431)*{Rcpt}{Pri}(432)} \right)} = {{{Src}{Data}(415)*(1)} = {> {{Src}{Data}{(415).}}}}}}} & {{Eq}.8}\end{matrix}$

Accordingly, the particular recipient device 430 may then process thedecrypted source data 415 in any way so configured/desired. Notably,“causing the particular recipient device 430 to decrypt” as used hereinmay generally imply that the recipient device 430, which now has theencrypted data 427 and the private key 432 to decrypt it, is enabled todecrypt the data as needed/desired—for instance, the recipient-basedencrypted source data 427 may simply be stored at the recipient device430 until one or more internal triggers at the recipient device actuallyresult in the decryption (e.g., a particular government agent becomingavailable to investigate a transaction).

As an example, based on certain triggers, the techniques herein may alsoprovide for reports 560 to be generated and associated with the sourcedata 415, notably where the reporting entity (e.g., the controllerdevice 440) does not have access to the source data being reported. Inthis instance, the request 550 to share the source data with theparticular recipient device may include an identification (e.g., a“request identification”) that would tie the source data to the report560 sent to the particular recipient device (e.g., separately from thesource data) with the same (request) identification, such as a reportnumber, transaction number, government tracking number, and so on. (Forexample, the identification may be included when sending the source dataencrypted with the recipient public key to the particular recipientdevice, as described below). The particular recipient device may thenconnect the decrypted source data 415 with the received report 560having the same identification (e.g., request identification). As oneexample of a report, the generation of a currency transaction report(CTR) as report 560 would need to be associated with particular sourcedata 415 (e.g., PII) of the source device (e.g., user) attempting tomake the trigger-inducing bank transfer, accordingly. Generally, thereport received by the recipient device may be initiated by and receivedfrom the controller device, though in other embodiments other devicesmay either initiate the report (e.g., the storage server) or may forwardthe report (e.g., the controller device sends the report to the storageserver, which sends the report along with the source-encrypted sourcedata).

FIG. 7 illustrates another representation 700 of the concepts describedin greater detail above. In particular, user data 710 (e.g., source data415) and the user's public key 715 (e.g., source encryption key 411)serve as inputs to an encrypting combination 720 to result in cipherdata 725 (e.g., source-encrypted source data 417). Additionally, theuser's private key 730 (e.g., source decryption key 412) and therecipient's public key 735 (e.g., recipient device public key 431)server as inputs to a second encrypting combination 740 to result in therekeying key 745 (e.g., recipient-based rekeying key 418). By thenproviding the cipher data 725 and the rekeying key 745 into another“re-” encrypting combination 750, the result is the new cipher data 755(e.g., recipient-based encrypted source data 427). Accordingly, bysupplying the recipient's private key 760 into a decrypting combination765 for the new cipher data 755 results in the decrypted user's raw data710.

Note that the techniques have thus far been described generally in termsof a single set of source data 415 and a single recipient device 430, aswell as the corresponding encrypting and decrypting combinations.However, it is important to note that the techniques herein specificallyprovide for advanced data management, and the storage server 420 maymanage different sets of source-encrypted source data 417(i) for each ofa plurality of source devices 410(i), and may maintain a plurality ofdifferent rekeying keys 418(i) for a plurality of correspondingrecipient devices 430(i). In this manner, a single set of data 415 for aparticular source device may be stored in encrypted form at the storageserver (source-encrypted source data 417), and then as that data is tobe shared with particular recipients, a corresponding rekeying key 418is either used (if pre-stored) or requested from the source device 410first and then used, accordingly (that is, such that the source devicemay generate it and send it in response to a specific request). As such,the source data 415 can still only be accessed by each particularreceiver device as directed (approved) by the source device, yet thestorage server also only needs to store one copy of the source-encryptedsource data (i.e., it need not store many copies of the same data withdifferent recipient-based encryptions).

For example, a source device may collect various types of source data415, such as PII (e.g., “415(PII)”), credit card account numbers (e.g.,“415(CC#)”), medical information (e.g., “415(med)”), and so on. Bystoring the single copy of each type of source data on the storageserver as correspondingly recipient agnostic source-encrypted sourcedata (e.g., 417(PII), 417(CC#), 417(med), respectively), then when thatparticular information is needed for a particular recipient, the properrecipient-based conversion can be made (e.g., sending the credit cardnumber to a first vendor recipient at one time, and then a second vendorrecipient at another time, or as another example sending the medicalinformation to an emergency room at a hospital, and then later to aspecialist doctor's office for a follow-up appointment.) Accordingly,when requests to send the stored information (source-encrypted sourcedata 417(i)) are received (and approved), a correspondingrecipient-based rekeying key is used to convert the stored (recipientagnostic) data 417 into the correctly re-encrypted recipient-basedencrypted source data 427(i) (e.g., to “427(med-hospital)” and then to“427(med-specialist)”, and so on).

This concept is illustrated generally with reference to FIG. 8A, showingan example storage system 800 in accordance with techniques herein, aswell as with reference to FIG. 9 , illustrating an example communicationexchange 900 between the devices of the system 800. For example, FIG. 8Aillustrates how the storage server 420 can manage data storage for asingle source device 410, though a similar model would exist for eachsource device serviced by the system.

The first consideration of scale for the storage system 800 is how thesource device can establish and send any number of recipient-basedrekeying keys 418(i) to the storage server. That is, eachrecipient-based rekeying key 418(i) corresponds to an encryptingcombination of the source decryption key 412 and a respective recipientpublic key 431(i) of a respective recipient device 430(i) from aplurality of recipient devices. For instance, in one embodiment here(e.g., where the particular recipient devices are pre-authorizedpartners to the system), the storage system herein may establish andstore one rekeying key for each entity/enterprise that is expected to bean available option as a particular recipient device 430(i). Forexample, if the storage system is configured to interface withparticular devices “n”, then a corresponding rekeying key “418(n)” maybe established, such as, for illustration, government devices (e.g.,rekeying key 418(gov)), retail/ecommerce companies (e.g., rekeying key418(retail)), a general medical/emergency authorization for relatedrecipient devices (e.g., rekeying key 418(emergency)), and any otherentity participating in the storage system (e.g., rekeying key418(entity-n)). Note that the source device 410 may also have separateencryption/decryption key pairs (411(i)/412(i)) as well for eachrecipient device, as described herein. The storage server 420 may thenbe configured to select a rekeying key based on the particular recipientdevice in the request 550 to share the source data 415 (i.e.,source-encrypted source data 417). Specifically, the storage serverselects a particular recipient-based rekeying key 418(i) of theplurality of recipient-based rekeying keys that corresponds to theparticular recipient device 430(i) for re-encrypting thesource-encrypted source data 417.

Notably, in one particular embodiment, certain recipient devices may begrouped into a group of categorically similar recipients that share agroup-based recipient public key 418(grp). For example, governmentbranches may be grouped into a single rekeying key (e.g., FinCEN, theIRS, the FBI, etc.), medical/emergency offices (all hospitals, doctors'offices, etc.) may be grouped into a single rekeying key, etc. What thisimplies, therefore, is that the “public key of the recipient device” 431may alternatively be a specific public key that is shared across aplurality of devices, such that the corresponding “private key of therecipient device” 432 is also shared (privately) amongst the groupmembers. As such, the public/private key pairs of these devices that aretypically used for communication and storage need not be the same keysused by the storage system herein. Instead, any encryption anddecryption keys could be used, where one is public to the storage system(i.e., recipient public key 431), and one is private to all devicesother than the particular recipient device or group of recipient devices(i.e., recipient private key 432).

The second consideration of scale for the storage system 800 isconfiguring the source device 410 to create and send a plurality of setsof source-encrypted source data 417(i), such as different types of datathat will be distributed to recipient devices separately. For instance,the information (source data) useful to certain recipients may beunnecessary at other recipients, or else the source device may desire tohave certain information shared with some recipients and not others. Asan example, a customer loyalty program would like to know a user'sshopping and spending habits, but need not have access to socialsecurity numbers, bank account numbers, and so on. Likewise, a hospitalis unlikely to need information pertaining to web browser searchhistory. Accordingly, a plurality of sets of source data 415(i) may beencrypted into source-encrypted source data 417(i) and sent to thestorage server 420 for secure storage. Moreover, therefore, thecombination of rekeying keys 418(i) to source-encrypted source data417(i) may be determined on-demand (e.g., applying a rekeying key“418(med)” for a medical office to the secured PII data “417(PII)” atone time, and then applying a different rekeying key “418(bank)” for abank to the secured PII data “417(PII)” at another time).

Note that according to certain embodiments herein, two or more sets ofsource-encrypted source data 417(i) may be associated (or bound)together, wherein each of the associated two or more sets individuallyrequires a respective recipient private key 432(i) to decrypt thecorresponding source data (i.e., once re-encrypted into recipient-basedencrypted source data 427), that is, where only certain devices canaccess certain corresponding portions of the associated data sets. Forexample, one of the sets of source data may be used for user-identifyinginformation (e.g., PII), while the other set(s) may be used for dataother than user-identifying information (e.g., customer loyalty habits,purchase history, medical history, etc.), but both (or all) of the datamay be sent as a single “package” of data, such as sending the identityinformation and non-identity at the same time. In this manner, finergranularity of control over the source data can be managed by thestorage system herein. In another embodiment, one set of data may beused for performance of an action (e.g., a financial transaction), andthe other set(s) may be for use in response to performance of the action(e.g., representing goods and/or services tendered through the financialtransaction). (For example, information regarding payment by a partywithout disclosing to the other party the account number (e.g., creditcard number/info) to the party that posts the charges—also optionallynot disclosing to the credit card company what is the item beingpurchased.)

The storage system may also be configured such that the request 550 toshare the source data with the particular recipient device alsocomprises an indication of a particular set of source-encrypted sourcedata 417(i) to share. As such, the storage server 420 may then select(based on the request to share the source data) the particular set ofsource-encrypted source data to re-encrypt with the recipient-basedrekeying key 418(i) and send to the particular recipient device 430(i).In this manner, the techniques herein allow for great efficiencies ofdata storage, such as encrypting and storing different sets of sourcedata (e.g., very large collections of data, such as shopping habits,lengthy secure PDFs, etc.) that can be securely shared to differentrecipients. (As an analogy, rather than storing one hundred differentsets of encrypted data, the techniques herein can instead store tendifferent sets of data and ten different rekeying keys for tenrecipients.)

For instance, with reference to scenario 800 b of FIG. 8B, the storageserver 420 may take two pieces of source data 415(a) and 415(b), andencrypt them with a source encryption key 411(i) (e.g., a samesource/public key for all encrypted source data, or different keys fordifferent reasons) into source-encrypted source data 417(a) and 417(b),respectively, in order to send the source-encrypted source data 417(a)and 417(b) to a first recipient device 430(a). Afterward, thesource-encrypted source data 417(b) may then be re-encrypted using therekeying key 418(a) of device 430(a) (into recipient-based encrypteddata 427(a)), and the source-encrypted source data 417(a) may bere-encrypted using the rekeying key 418(b) of a second recipient device430(b) (into recipient-based encrypted data 427(b)). A computed hash 490of the combined data can then be added, such that the first recipientdevice 430(a) can be assured that both the first and second portion ofthe data (namely both 427(a) and 427(b)) are appropriately bound uponreceipt. Now, device 430(a) may decrypt its corresponding data 427(a)(to get source data 415(b)), may process the visible data (e.g.,generate reporting on the data), and then can send the package of data(427(b) and the decrypted data 415(b)) to the second recipient device430(b) to decrypt and process the other portion of the data 427(b)(i.e., decrypt its corresponding data 427(b) to get source data 415(a))in addition to the previously decrypted source data 415(b). (Note thatpreviously decrypted source data 415(b) may be removed by recipientdevice 430(a) or the originally encrypted version 427(a) may be used inorder to match the hash 490, depending upon configuration.)

As a more concrete example, assume that a bank wants to sharetransaction information of a user with a certain identity with areporting service, which prepares reports based on the transactioninformation, but does not need (e.g., or should not have in certainembodiments) the user's identity. (For example, the information may beassociated with an “entity-based operation report” sent to theparticular recipient, such as a financial transaction operation orotherwise.) The report may then be prepared based on the decryptedtransaction information, and then sent to a final regulatory device tofurther decrypt the identity information associated with the report.Another example may be a serially secure transaction, such as creditcard or online payment transactions prompting delivery of goods,“relay-style” manufacturing of goods (e.g., top-secret manufacturing,where one process cannot start until another is finished, but withoutsharing the details of each with the teams performing themanufacturing), and so on. Many configurations of source dataassociations are possible herein, and notably in the case where aplurality of associated data sets are to be shared with a particularrecipient device (e.g., user-identifying information and/or otherinformation), then the storage server may re-encrypt all of the desiredsets of data with the same rekeying key as directed by the request,accordingly.

Notably, for the sake of simplicity, FIG. 8A describes source device 410encrypting all of the different pieces of information with the sameencryption key/public key (e.g., a single version of PII source data415(PII) stored as a single source-encrypted source data 417(PII) forthe PII, able to be re-encrypted later for any eventual recipient asrecipient-based encrypted source data 427). However, the techniquesherein also contemplate deployments where the source device 410 may usea different key pair for each of the different pieces of information foreven greater security management. For instance, multiple sourceencryption and decryption keys may be used, where each different datasetmay be accompanied with a different source encryption/decryption keypair (and thus with a different recipient-based rekeying key). As afirst example, a single set of PII 415(PII) may be stored on the storageserver for recipient “A” using a first encryption key “key-A”, resultingin source-encrypted source data 417(PII-A), and a second copy may alsobe stored using a second encryption key “B” for recipient “B” assource-encrypted source data 417(PII-B). Here, therefore, a firstrekeying key would need to be used in order for recipient A to receivethe PII (i.e., a combination of a corresponding decryption key for“key-A” and the recipient public key for recipient A), and a secondrekeying key would need to be generated with a different decryption keyfor “key-B” (and the recipient public key for recipient B). As a secondexample, a first set of PII may be generated by the source device forrecipient “A” (source data 415(PII-A)), and a second set of PII may bestored for recipient “B” (415(PII-B)), where the PII itself may be thesame or different information, but where regardless, two sets ofsource-encrypted source data 417(PII-A) and 417(PII-B) are created andstored on the storage server (using a single encryption key of thesource device, or else different keys as mentioned above). In theseways, the techniques herein further isolate recipient devices from oneanother and their ability to decipher data not intended specifically forthe respective recipient device (e.g., for malicious cross-overdecryption attempts, or in the event the storage server ever makes amistake and rekeys the wrong dataset with a wrong rekeying key and sendsit to the wrong party, since only the correctly intended combinationaccording to the source device would result in a properly decrypteddataset.

As a more specific explanation of the techniques mentioned above withreference to FIG. 8B, in addition to parallel processing of associateddata, the embodiments herein may also specifically consider seriallyprocessed data sets. For instance, when the source data comprises two ormore sets of data associated together (e.g., 415(a) and 415(b)), eachrequiring a respective rekeying key to re-encrypt the correspondingsource data (i.e., a first data set to be decrypted (readable) only by afirst recipient device, and a second data set readable only by a secondrecipient device), then various configurations and perspectives ofsecure data management may occur according to the zero-knowledge datamanagement techniques herein. For instance, upon sending/receiving anindication that the first data set was successfully processed by thefirst recipient device, the second recipient device may then process itsown decrypted source data (e.g., from the recipient-based encryptedsource data) based on the indication that the first data set wassuccessfully processed. Alternatively or in addition, both sets of datamay be sent to the first device, and then after processing the data, thefirst recipient device can send the indication that the first data setwas successfully processed (e.g., completed, attested to, verified,etc.), the second set of data (still unreadable to the first recipientdevice), and/or some other processed set of data produced by processingthe first set of data at the first recipient device.

Regarding the persistent storage of encryption keys and data establishedbased on those keys, according to conventional computer networking,encryption keys (e.g., public/private key pairs) typically have alifespan, and are rotated occasionally after being used for a givenlength of time (e.g., automatically updating or updating based onadministrator control). This is due to the fact that the more aparticular key is used, the more clues are given to would-be hackersattempting to break the encryption. However, in the event thatrecipient-based rekeying keys 418 are stored at the storage server 420for a duration that overlaps with such a key rotation, then the factthat the recipient-based rekeying keys are based on an older recipientpublic key 431 would mean that the newer recipient private key 432 wouldno longer work to decrypt the corresponding recipient-based encryptedsource data 427 (i.e., the old public key and new private key would notbe properly paired).

In order to account for such key rotation, the embodiments hereinfurther provide for a re-encryption technique that allows for updating,or more particularly rotating the recipient public key from an originalrecipient public key 431_t to a rotated recipient public key 431_t+1,and rotating the corresponding recipient private key from an originalrecipient private key 432_t to a rotated recipient private key 432_t+1.In particular, when a recipient device 430 (or any device as needed, asdescribed herein) has a (Pub, Pri) key pair at time “t” that is rotatedto a new (Pub, Pri) at time “t+1”, the techniques herein have therotating device (e.g., the recipient device 430) establish a “recipientre-encryption key” 433 (with reference to FIG. 4 ). The recipientre-encryption key 433 may be established through an encryptingcombination of the original recipient private key 432_t and the rotated(updated) recipient public key 431_t+1. In particular, recall from Eq. 5above that:

Src Data (415)*Src Pub (411)=>Src-Encrypt Src Data (417)  (Eq. 5 above),

and also that at time “t”, from Eq. 6 above, that:

Src Pri (412)*Rcpt Pub (431_t)=>Rcpt-Bsd Rekey Key (418_t)  (Eq. 6above).

As such, the storage server 420 may request to receive, or the recipientdevice may push, a new recipient re-encryption key 433 (“Rcpt Re-EncryptKey”), which is an encrypting combination of the original recipientprivate key 432_t and the rotated recipient public key 431_t+1 as shownbelow, and with reference to FIG. 10A:

Rcpt Pri (432_t)*Rcpt Pub (431_t+1)=>Rcpt Re-Encrypt Key (433_t+1)  Eq.9.

By sending the recipient re-encryption key 433_t+1 to the storage server420, the storage server receives and applies the recipient re-encryptionkey to the recipient-based rekeying key 418_t to generate an updatedrecipient-based rekeying key 418_t+1 that is an encrypting combinationof the source decryption key 411 and the rotated recipient public key431_t+1, shown as follows and in FIG. 10B:

$\begin{matrix}{{{Rcpt} - {Bsd}{Rekey}{Key}\left( {418{\_ t}} \right)*{Rcpt}{Re} - {Encrypt}{Key}\left( {{433{\_ t}} + 1} \right)} = {{\left( {{Src}{Pri}(412)*{Rcpt}{Pub}\left( {431{\_ t}} \right)} \right)*\left( {{Rcpt}{{Pri}\left( {432{\_ t}} \right)}*{Rcpt}{Pub}\left( {{431{\_ t}} + 1} \right)} \right)} = {{{Src}{Pri}(412)*\left( {{Rcpt}{Pub}\left( {431{\_ t}} \right)*{Rcpt}{Pri}\left( {432{\_ t}} \right)} \right)*{Rcpt}{Pub}\left( {{431{\_ t}} + 1} \right)} = {{{Src}{Pri}(412)*(1)*{Rcpt}{Pub}\left( {{431{\_ t}} + 1} \right)} = {{{Src}{Pri}(412)*{Rcpt}{Pub}\left( {{431{\_ t}} + 1} \right)} = {> {{Rcpt} - {Bsd}{Rekey}{Key}{\left( {{418{\_ t}} + 1} \right).}}}}}}}} & {{Eq}.10}\end{matrix}$

Notably, the storage server 420 is never in knowledgeable possession ofany private keys of the recipient device in the process of re-encryptingthe rekeying key based on the rotated (updated) public/private keypairs.

Now, in the event that the storage server 420 is requested to share thesource-encrypted source data 417 with a particular recipient after timet+1, then the recipient-based encrypted source data 427 (427_t+1) is theresult of the source data 415 being encrypted with the updated recipientpublic key 431_t+1 (i.e., is based on the rotated recipient publickey/private key pair), as illustrated below, and with reference to FIG.10C:

$\begin{matrix}{{{Src} - {Encrypt}{Src}{Data}(417)*{Rcpt} - {Bsd}{Rekey}{Key}\left( {{418{\_ t}} + 1} \right)} = {{\left( {{Src}{Data}(415)*{Src}{Pub}(411)} \right)*\left( {{Src}{Pri}(412)*{Rcpt}{Pub}\left( {{431{\_ t}} + 1} \right)} \right)} = {{{Src}{Data}(415)*\left( {{Src}{Pub}(411)*{Src}{Pri}(412)} \right)*{Rcpt}{{Pub}\left( {{431{\_ t}} + 1} \right)}} = {{{Src}{Data}(415)*(1)*{Rcpt}{Pub}\left( {{431{\_ t}} + 1} \right)} = {{{Src}{Data}(415)*{Rcpt}{Pub}\left( {{431{\_ t}} + 1} \right)} = {> {{Rcpt} - {Bsd}{Encrypt}{Src}{Data}{\left( {{427{\_ t}} + 1} \right).}}}}}}}} & {{Eq}.11}\end{matrix}$

Accordingly, the decrypting of the recipient-based encrypted source data(427_t+1) is based on the updated recipient private key 432_t+1 in orderto obtain the original source data 415, as shown below and withreference to FIG. 10D:

$\begin{matrix}{{{Rcpt} - {Bsd}{Encrypt}{Src}{Data}\left( {{427{\_ t}} + 1} \right)*{Rcpt}{Pri}\left( {{432{\_ t}} + 1} \right)} = {{\left( {{Src}{Data}(415)*{Rcpt}{Pub}\left( {{431{\_ t}} + 1} \right)} \right)*{Rcpt}{Pri}\left( {{432{\_ t}} + 1} \right)} = {{{Src}{Data}(415)*\left( {{Rcpt}{Pub}\left( {{431{\_ t}} + 1} \right)*{Rcpt}{Pri}\left( {{432{\_ t}} + 1} \right)} \right)} = {{{Src}{Data}(415)*(1)} = {> {{Src}{Data}{(415).}}}}}}} & {{Eq}.12}\end{matrix}$

Notably, in one embodiment herein, the source device 410 sends thesource-encrypted source data 417 and the recipient-based rekeying-key(s)418 at generally the same time, that is, while the source device'sencryption and decryption keys (e.g., public and private keys) 411/412are still paired and of the same generation “t”. For example, the sourcedevice may obtain the source data 415, and after encrypting it with itspublic key may send it to the storage server 420 for storage along withthe rekeying key(s) necessary to re-encrypt the data depending upon theparticular recipient devices set to receive the data in the future. Insuch embodiments, there is no need to update either the encrypted sourcedata or the rekeying keys in response to the source device's encryptionand decryption keys (e.g., public and private keys) 411/412 beingrotated from an original generation “t” to a new generation “t+1”. Inparticular, the source-encrypted source data 417_t is encrypted with the“original” encryption key 411_t, and the stored recipient-based rekeyingkey 418_t is based on the “original” decryption key 412_t, and thus evenin the event that the updated keys 411_t+1/412_t+1 are in use, thestored source-encrypted source data 417_t and stored recipient-basedrekeying-key(s) 418_t are of the same generation, and the keys areappropriately paired.

However, there may be embodiments where the source-encrypted source data417 and the recipient-based rekeying key(s) 418 are not sent generallycontemporaneously. For instance, in certain embodiments, the sourcedevice 410 may obtain source data 415, and may wish to encrypt it andstore it securely at the storage server 420, without knowing yet whowill be able to receive it in the future. For example, file storage,document storage, data archival, generalized identity storage for usewith future recipients requesting such data, and so on, are all possiblescenarios where the source-encrypted source data 417 is stored well inadvance of the establishment of any corresponding recipient-basedrekeying key(s) 418. The techniques herein, therefore, address thesescenarios with a variety of configurable options. First, the encryptionkey 411 and decryption key 412 need not be tied to the source device'spublic and private keys, respectively. That is, the keys used by thesource device 410 for data storage in the zero-knowledge data managementsystem herein can be a specifically dedicated key pair, and need not beupdated along with the general (pub,pri) key pair of the source device.In a second embodiment, the source device may maintain older keys(particularly older decryption/private keys 412 t), and can correlatethe older keys with older stored source-encrypted source data 417 inorder to establish appropriately paired recipient-based rekeying keys418 that correspond to the same generation of key pairing from the timeat which the source-encrypted source data 417 was first created andstored. In a third embodiment, such as where the data is notparticularly large (e.g., simply identity data), then it's possible tohave the source device create new source-encrypted source data 417_t+1(and possibly with new/update source data 415_t+1) using the new keys,and replacing the older version of the source-encrypted source data417_t stored at the storage server 420.

In still another embodiment to address rotating keys at the sourcedevice, rather than maintaining old keys (especially where data archivalis used over the course of many years), the techniques herein mayprovide a mechanism for updating the source-encrypted source data 417_tto the new source device keys. For instance, recall again from abovethat source-encrypted source data 417_t at time “t” is based on thesource data 415_t and source encryption (e.g., public) key 411_t:

Src Data (415_t)*Src Pub (411_t)=>Src-Encrypt Src Data (417_t)  (Eq. 5above).

As such, in order to allow for the use of an updated decryption (e.g.,private) key 412_t+1 in the future with the source-encrypted source data417 (with source data 415_t), which namely would appear in the futureas:

Src Pri (412_t+1)*Rcpt Pub (431)=>Rcpt-Bsd Rekey Key (418_t+1)  (Eq. 6above),

then the techniques herein must provide an update to thesource-encrypted source data using a “source data re-encryption key” 419(“Src Data Re-Encrypt Key”), which is an encrypting combination of theoriginal source decryption (e.g., private) key 412_t and the updatedsource encryption (e.g., public) key 411_t+1, as shown below, and withreference to FIG. 11A:

Src Pri (412_t)*Src Pub (411_t+1)=>Src Data Re-Encrypt Key(419_t+1)  Eq. 13.

By sending the source data re-encryption key 419_t+1 to the storageserver 420, the storage server receives and applies the source datare-encryption key to the source-encrypted source data 417_t to generatean updated source-encrypted source data 417_t+1 that is the originalsource data 415_t encrypted by the updated source encryption key411_t+1, shown as follows and in FIG. 11B:

$\begin{matrix}{{{Src} - {Encrypt}{Src}{Data}\left( {417{\_ t}} \right)*{Src}{Data}{Re} - {Encrypt}{Key}\left( {{419{\_ t}} + 1} \right)} = {{\left( {{Src}{Data}\left( {415{\_ t}} \right)*{Src}{Pub}\left( {411{\_ t}} \right)} \right)*\left( {{Src}{Pri}\left( {412{\_ t}} \right)*{Src}{Pub}\left( {{411{\_ t}} + 1} \right)} \right)} = {{{Src}{Data}\left( {415{\_ t}} \right)*\left( {{Src}{Pub}\left( {411{\_ t}} \right)*{Src}{Pri}\left( {412{\_ t}} \right)} \right)*{Src}{Pub}\left( {{411{\_ t}} + 1} \right)} = {{{Src}{Data}\left( {415{\_ t}} \right)*(1)*{Src}{Pub}\left( {{411{\_ t}} + 1} \right)} = {{{Src}{Data}\left( {415{\_ t}} \right)*{Src}{Pub}\left( {{411{\_ t}} + 1} \right)} = {> {{Src\_ Encrypt}{Src}{Data}{\left( {{417{\_ t}} + 1} \right).}}}}}}}} & {{Eq}.14}\end{matrix}$

Just as noted with regard to the recipient-based rekeying key above, thestorage server 420 is never in knowledgeable possession of any privatekeys of the source device in the process of re-encrypting the sourcedata 415 based on the rotated (updated) encryption/decryption (e.g.,public/private) key pairs of the source device.

Now that the storage server 420 has the updated source-encrypted sourcedata 417_t+1, recipient-based rekeying key(s) 418_t+1 may be establishedbased on the updated source decryption key 412_t+1, such that therecipient-based encrypted source data 427 (notably with the originalsource data 415_t) would be created as follows:

$\begin{matrix}{{{Src} - {Encrypt}{Src}{Data}\left( {{417{\_ t}} + 1} \right)*{Rcpt} - {Bsd}{Rekey}{Key}\left( {{418{\_ t}} + 1} \right)} = {{\left( {{Src}{Data}\left( {415{\_ t}} \right)*{Src}{Pub}\left( {{411{\_ t}} + 1} \right)} \right)*\left( {{Src}{Pri}\left( {{412{\_ t}} + 1} \right)*{Rpt}{Pub}(431)} \right)} = {{{Src}{Data}\left( {415{\_ t}} \right)*\left( {{Src}{Pub}\left( {{411{\_ t}} + 1} \right)*{Src}{Pri}\left( {{412{\_ t}} + 1} \right)} \right)*{.{Rcpt}}{Pub}(431)} = {{{Src}{Data}\left( {415{\_ t}} \right)*(1)*{Rcpt}{Pub}(431)} = {{{Src}{Data}\left( {415{\_ t}} \right)*{Rcpt}{Pub}(431)} = {> {{Rcpt} - {Bsd}{Encrypt}{Src}{Data}{(427).}}}}}}}} & \left( {{{Eq}.7}{above}} \right)\end{matrix}$

Note that the recipient public key 431 used in the recipient-basedrekeying key 418_t+1 may be from any generation (e.g., “t” or “t+1”),and may be updated as needed according to the recipient re-encryptionkey 433 as described above.

By updating the source-encrypted source data 417_t+1 in this manner, anypreviously stored recipient-based rekeying keys 418_t, assuming thestorage system is configured to store rekeying keys in advance ofrequests to share data, will immediately become obsolete at the storageserver. That is, any rekeying key based on the previous decryption key412_t will no longer pair with the update encryption key 411_t+1. Twooptions are available to account for this type of system configuration.First, all currently stored recipient-based rekeying keys 418_t cansimply be updated (i.e., recreated based on updated keys to 418_t+1).Alternatively, such as where many recipient-based rekeying keys 418_tare stored, the techniques herein may provide for a “source-basedre-encryption key” 413 (“Src-Bsd Re-Encrypt Key”) that can be used toupdate any previously stored recipient-based rekeying keys 418_t. Inparticular, the source-based re-encryption key 413 may be establishedthrough an encrypting combination of the original source encryption(e.g., public) key 411_t and the updated source decryption (e.g.,private) key 412_t+1 as shown below, and with reference to FIG. 12A:

Src Pub (411_t)*Src Pri (412_t+1)=>Src-Bsd Re-Encrypt Key (413_t+1)  Eq.15.

By sending the source-based re-encryption key 413_t+1 to the storageserver 420, the storage server receives and applies the source-basedre-encryption key to the recipient-based rekeying key 418_t to generatean updated recipient-based rekeying key 418_t+1 that is an encryptingcombination of the updated source decryption key 412_t+1 and therecipient public key 431, shown as follows and in FIG. 12B:

$\begin{matrix}{{{Rcpt} - {Bsd}{Rekey}{Key}\left( {418{\_ t}} \right)*{Src} - {Bsd}{Re} - {Encrypt}{Key}\left( {{413{\_ t}} + 1} \right)} = {{\left( {{Src}{Pri}\left( {412{\_ t}} \right)*{Rcpt}{Pub}(431)} \right)*\left( {{Src}{Pub}\left( {411{\_ t}} \right)*{Src}{{Pri}\left( {{412{\_ t}} + 1} \right)}} \right)} = \left( {{{Src}{{Pri}\left( {412{\_ t}} \right)}*\left( {{Src}{Pub}\left( {411{\_ t}} \right)} \right)*{Src}{{Pri}\left( {{412{\_ t}} + 1} \right)}*{Rcpt}{Pub}(431)} = {{(1)*{Src}{{Pri}\left( {{412{\_ t}} + 1} \right)}*{Rcpt}{Pub}(431)} = {{{Src}{Pri}\left( {{412{\_ t}} + 1} \right)*{Rcpt}{Pub}(431)} = {> {{Rcpt} - {Bsd}{Rekey}{Key}{\left( {{418{\_ t}} + 1} \right).}}}}}} \right.}} & {{Eq}.16}\end{matrix}$

Still, the storage server 420 is never in knowledgeable possession ofany private keys of the source device in the process of re-encryptingthe recipient-based rekeying key 418 based on the rotated (updated)encryption/decryption (e.g., public/private) key pairs of the sourcedevice. Note also that updating the recipient-based rekeying key 418 inthis manner also does not preclude re-updating it, based on either thesource device's key rotation above, or based on the recipient device'skey rotation even further above.

Notably, though certain embodiments herein allow for source devices torotate their keys as described above, other embodiments may limit theability of source devices to do so. For instance, high-security or highuser-trackable embodiments herein may require that the integrity of theinitial source data be maintained and unaltered throughout its lifetime.For example, when obtaining new PII/KYC information for a new user(which may be attested to as described below), that original informationwould be meant for use for generating reports at a later time (e.g.,government reporting). However, if the user is in-fact malicious, he orshe can provide bogus rotated keys to re-encrypt the source data (thePII) so that when the government asks for (or otherwise receives) theKYC information from the storage server, the recipient-based rekeyingkey would actually create data that is undecipherable to the government(i.e., the malicious/criminal user has erased all traces of the PII/KYCinformation by re-encrypting the data with the bogus keys). As such, theability for a source device to rotate keys in the manner described abovemay be reserved for otherwise trusted situations (e.g., more akin topassword updating over time for private storage of source data on remoteservers). In such instances that prevent source device key rotation,therefore, the techniques herein may force any source device thatrotates its keys as a new source device (e.g., new user) that signs into the system, or may require new source data to be stored, accordingly.

According to the zero-knowledge data management techniques herein,therefore, source data becomes much more difficult to obtain by hackersor other unauthorized systems. This is especially true at the storageserver 420 and the controller device 440, which cannot read theencrypted source data, nor do they store any keys that could open theencrypted source data by anyone other than an authorized device (thuseven preventing employees of data storage companies with access to thestorage server 420 from compromising the data since stealing the datafrom the storage server 420 results in obtaining encrypted/unreadabledata). In other words, the data that is stored on the storage server 420is unreadable by the storage server, and unreadable by anyone else otherthan the source device who originated the data, and by a devicespecifically authorized by the source device (and notably not thecontroller device). In fact, the only useful targets for would-behackers would be the source device 410 and the particular recipientdevices 430. At the source device, obtaining a single source of data islikely not worth the effort of hacking (and is still optionallyprevented herein by having the source device delete or generally notstore the original raw data 415 after it is encrypted intosource-encrypted source data 417, requiring the hacker to also haveaccess to the decryption/private key 412 of the source device). At therecipient devices, which in certain embodiments are government devicesnot easily hacked, the decrypted source data may be deleted (not stored)after processing, reducing the risk of data being accessible. Forexample, if the source data is credit card information, a retail devicemay obtain the information, process it to perform a transaction, andthen delete it/not store it. If the information is needed again(including for certain websites that store consumer profile and creditcard information), then the information can be obtained again from thestorage server 420 as needed (and, notably, the source data may haveeven been updated in the interim).

Still, one potential attack on obtaining source data from one or even aplethora of source devices is a phishing or spear-fishing attempt.Generally, phishing is the fraudulent practice of purporting to be froma reputable company in order to induce individuals to reveal personalinformation, such as passwords and credit card numbers, whilespear-phishing is the research-based practice of pretending to be aknown or trusted sender in order to induce specifically targetedindividuals to reveal confidential information or transfer funds.Through such a practice, it is possible that a source device (or theuser at the source device) could be fooled into authorizing the sharingof sensitive source data with an otherwise unauthorized recipientdevice. According to one or more embodiments of the zero-knowledge datamanagement system herein, therefore, an additional layer of security maybe added at the storage server 420 to prevent the source device 410 frominadvertently authorizing the sharing of its source data with anunscrupulous device.

In particular, in order to prevent such phishing or spear-phishingattempts, as well as other known or detectable recipient-based threats(e.g., compromising the integrity of the requesting mechanisms, such asacting as a trusted controller device or gaining control over authorizeddevices), the techniques herein allow the storage server 420 to filteror otherwise additionally manage the sharing of the source data. Thatis, while limiting access of the source data 415 with particularrecipient devices 430 to only those devices specifically authorized bythe source device is a first line of defense against unauthorized accessto the data (i.e., only the requested recipient devices can decrypt thedata), the techniques herein can essentially intercept the passing ofthe source data (e.g., can preclude sharing the source-encrypted sourcedata 417 from the storage server) to prevent misappropriation of thesource data to “requested recipient devices” that may, in fact (or byassumption), be improper recipients of the data.

According to these particular embodiments, therefore, the techniquesherein may configure the storage server 420 to confirm, in response toreceiving the request 550 to share the source data 415 with theparticular recipient device 430, that the particular recipient device430 is actually authorized to receive the source data. Note that asexplained above, sharing the encrypted data with a malicious hackerpretending to be an actually authorized recipient device 430 would notreveal any information since the hacker would need to gain access to theprivate key of the recipient device before the information becomesuseful (i.e., the data would be encrypted with the actually authorizedrecipient device's public key). However, with regard to these particularembodiments (e.g., where the storage server 420 doesn't know or care whorecipient device “X” is and simply re-encrypts the source-encryptedsource data with X's public key based on a correspondingsource-generated rekeying key for X at the request from source device),the techniques herein may also be configured to prevent situations wherethe source device 410 is able to decide/dictate which recipient devicesare authorized to receive the data, but where the storage server, ineffect, “knows better” than to share the data with certain recipients.(For instance, imagine a situation where a user receives animitation/forged email from “their bank” or from a fake online store toshare financial information, e.g., by simply “clicking this link toshare your source data”. The user/source device could then be trickedinto permitting access to the malicious recipient device according tothe link. In such situations, for example, the storage server mayalready be aware of the malicious recipient device and its deviouspractices, and would thus want to intervene by specifically notre-encrypting the source-encrypted source data 417 with the maliciousrecipient device's public key, accordingly.)

In particular, and with reference generally to FIGS. 13-14 , the storageserver may check the particular recipient device 430 against a list 1300that dictates the approval or denial of sharing the source data. Forinstance, the list 1300 may comprise entries 1310 and actions 1320,unless being on the list defines the action such as a whitelist (allowthese entries only) or a blacklist (deny these entries only). Otherlists, such as an access control list (ACL) may define more detailedpolicy-based decisions (e.g., deny these entries, unless theseconditions exist, or allow certain entries unless certain conditionsexist, etc.). In general, the list may thus be based on one or both ofauthorized recipients and unauthorized recipients. As such, determiningwhether the particular recipient device is authorized to receive thesource data is completed according to checking the list.

Notably, the list 1300 (or generally, any suitable access controlmechanism) may be based on credentials, device identifications (e.g.,specific recipient devices), and/or network domains (e.g., knownattacking networks, address prefixes, autonomous systems, uniformresource locators (URLs), and so on), as well as other factors such asgeography. In addition to simple listing of allow/deny entries, thetechniques herein also allow for authorization policies to be defined,such as time of day, day of week, size of data, frequency of datasharing, and many others. Further, whether the particular recipientdevice is authorized to receive the source data may be based oncombinations of factors, such as defining relationships betweenparticular source devices being asked to send to particular recipientdevices (e.g., some recipient devices are acceptable for some sourcedevices but not others, such as making the list 1300 specific toindividual source devices), particular source data being sent toparticular recipient devices (e.g., certain types of data are allowableto certain recipients but not others, such as preventing medicalinformation from being sent to financial institutions). Still otherentries may simply correspond to particular recipient devices itself(e.g., never allow data to be sent to certain recipients). Manydifferent types of authorization policies can be configured, includingparental controls, one-time access limits, and so on, and those shownherein are merely examples.

In one embodiment, the list 1300 and associated policies may bestatically configured, such as where an administrator sets the list inadvance of operation, and only during updates or routine maintenance arethe entries 1310 (and/or actions 1320) updated. In another embodiment,the list may be dynamically configured, changing over time as threatsare detected, policies are changed, tolerances are adjusted, and so on.(Note, too, that both static and dynamic configurations may occur withina same list, i.e., where at least a portion of the list is staticallyconfigured, and at least a portion of the list is dynamicallyconfigured). For example, the storage server 420 may receiving one ormore of the entries 1310 for the list from a controller device 440, inorder for the storage server to determine authorizations for devices toreceive the source data (e.g., where the controller device directs thecollection of the source data). The list may also be based on users atthe source devices 410 providing access to data, such as throughclickwrap or clickthrough agreements on particular applications (i.e., adigital prompt that offers individuals the opportunity to accept ordecline a digitally-mediated policy) or other user-based access control.

In another example, the dynamically configured entries may be based onbehavioral analytics (e.g., machine learning) techniques (e.g.,determining whether the particular recipient is authorized to receivethe source data according to behavioral analytics). In particular, aswill be appreciated by those skilled in the art, behavioral analyticstakes data points and attempts to determine past behavior and predictfuture trends. It is a field of machine learning, which uses statisticaltechniques to give computer systems the ability to “learn” (e.g.,progressively improve performance on a specific task) with data, withoutbeing explicitly programmed. Behavioral analytics may be based on asingle source device or based on observations across a plurality ofsource devices, and may determine a “baseline” behavior of sharingsource data. For example, assume that it is learned that most requeststo share data are one-time requests for a given source device to oneparticular recipient device. However, an alarming condition may betriggered when one particular recipient device is asking for much moredata and for different data types from the same source device. Manyother conditions may be established as baseline conditions, from whichclearly improper behavior or at least anomaly behavior (not expected)can be determined.

Note that although the above embodiments are specifically based onsecurity implemented at the storage server 420, the security (e.g., thelist 1300) may also be stored and managed at the source device 410(e.g., a centrally managed list, but distributed for localimplementation by the source devices). Alternatively or in addition,security protections may also be provided by other network devices, suchas by including the list 1300 in the network (e.g., in routers,firewalls, etc.). Still other network-based protection is alsocontemplated herein, such as private LANs and other network-centricprotection methods understood by those skilled in the art, and suchtechniques may be utilized by a system in accordance with thisdisclosure, accordingly.

In addition to the list-based approach, the techniques herein may alsoconfirm whether a particular recipient device is authorized to receivethe source data using a credential-based exchange between the storageserver 420 and the particular recipient device 430. For instance, inembodiments where the particular recipient devices are notpre-authorized (e.g., not merely a select few systems participating inthe storage system, but rather allowing for any device to be a possiblerecipient device), the techniques herein may have the storage serverrequest authentication credentials from the particular (potential)recipient device, which after the potential recipient device providesthose authentication credentials 1430 to the storage server (e.g.,passwords, access codes, attestation signatures to prove they are whothey say they are, etc.), then the storage server can confirm (or deny)the authentication credentials from the particular recipient device,accordingly.

As such, the techniques herein may thus prevent (deny) access by theparticular recipient device to the source data in response to theparticular recipient device not being authorized to receive the sourcedata, e.g., for any of the reasons mentioned above. In one embodiment,preventing (denying) access may be based on preventing the re-encryptingof the source-encrypted source data 417 with the recipient-basedrekeying key 418 and the sending of the recipient-based encrypted sourcedata 427 to the particular recipient device 430. In another embodiment,the storage server may also prevent the establishment of therecipient-based rekeying key 418, such as by not sending the public keyof the recipient to the source device. Note that in various specificembodiments, the storage server may respond to the request to share thesource data with the particular recipient device with a reason denial1440 of the request (e.g., to the requesting device, such as the sourcedevice, controller device, etc.), or else the request may simply beignored.

The zero-knowledge data management system described above thus limitsauthorized access of the source data 415 (e.g., limiting sharing ofsource-encrypted source data 417) to designated recipient devices 430,and also ensures that those recipients are valid and trusted entities.However, in certain data sharing environments, this raises the questionof whether devices without access to the data, such as the controllerdevices 440, can trust the contents of the data without knowing what thedata is. Data integrity, for example, is critical for many systems thatstore, process, and retrieve data, particularly to be able to provideassurance of the accuracy and consistency of data (e.g., recordsmanagement, healthcare records, legal or governmental documentmanagement, and so on). For instance, though the security measuresdiscussed above have generally addressed the possibility of compromisingthe data by delivering it to an unauthorized entity, source devices canalso be hacked, such that the source data 415 may have been editedbefore it is sent, such as for Trojan viruses or other malware, as wellas intentionally deceptive data transfer practices (e.g., providingfalse or revised documents, and so on).

Additionally, identity information, such as the Know Your Customer (KYC)data mentioned above, is also critical for systems that operate, in atleast some capacity, based on the provable identity of a user. Inparticular, source devices can also be spoofed (i.e., the source deviceidentifies itself as legitimate, when it is in fact only pretending tobe the identified source device), or users themselves can provide falseidentification (e.g., for money laundering, spear-phishing, or othercriminal or generally malicious intent). For example, while onlinegaming is one area where proving a gamer's real-life identity is likelynot critical to the operation of the game, banking, on the other hand,is governmentally regulated to require customer identification to beassociated with bank accounts. That is, though banks themselves may notneed to know more than an account number in order to perform atransaction, name matching against lists of known parties (such as a“politically exposed person” or PEP), determination of the customer'srisk in terms of propensity to commit money laundering, terroristfinance, or identity theft, and a plethora of other reasons have createdthe requirement by many governments that financial institutions need toverify the identity of individuals wishing to conduct financialtransactions with them (e.g., Bank Secrecy Act/Anti-money launderingcompliance programs). Specifically, as noted above, strict backgroundchecks are necessary and information must be shared from many differentfinancial institutions in order to help combat money laundering due tooften complex ownership and company structures. In addition to banks,too, customers of various businesses, such as retail merchants, areoften required to present an identification to complete a transaction orto sign up for a service. For instance, a merchant may require customeridentification for various types of purchases (e.g., alcohol, lottery,or tobacco purchases) or when certain types of payments (e.g., checks,credit cards) are presented to pay for transactions. Other reasons foridentity verification include “sockpuppetry”, underage signups,spamming, and illegal activities like harassment, scams, and moneylaundering through social media sites.

According to one or more additional embodiments of the presentdisclosure, therefore, techniques are described herein that allow fordevices without access to the source data 415 (e.g., controller devices440, recipient devices 430 before being granted access to the data, thestorage server 420, etc.) to trust the contents of the data,specifically without being able to decrypt and access (e.g., read) thedata. Specifically, as described below, the zero-knowledge datamanagement system herein can strategically employ the use of anattestation service (e.g., identity verification service), withcontrolled and limited access to the source data.

FIG. 15 illustrates an example attestation service system 1500,generally based on the storage system 400 above, with the addition of anattestation server 1510. Generally, attestation server 1510 may beconfigured as a verification service that comprises one or both ofautomated attestation or manually assisted attestation techniques, asgenerally understood by those skilled in the art. For example, a typicalidentity verification service, in particular, ensures that users orcustomers provide information that is associated with the identity of areal person, such as by verifying the authenticity of physical identitydocuments such as a driver's license or passport (“documentaryverification”), and/or by verify identity information againstauthoritative sources such as a credit bureau or government data(“non-documentary verification”). Manually-assisted techniques, whichmay be performed also through artificial intelligence, may includeidentity verification through webcams (e.g., holding up a driver'slicense next to a user's face to confirm the visual comparison and thedata on the license). Identity “scoring” (e.g., likelihood that a useris who they say they are) may also be used and shared as a result, e.g.,rather than (or in addition to) a simple yes/no or verified/not result.To attest to data integrity (e.g., validity, completeness, etc.), on theother hand, various methods of trusted computing and remote attestationmay be used, allowing a program at the source device to authenticateitself (e.g., the software/version running at the source device) or thedata (e.g., computed hashes, configuration data, revision tracking, andother data/meta-data-based information). Completeness of therecords/data may also be attested to, such as confirmations that allrequested data fields have been filled in with legitimate answers, evenif the accuracy of the answers themselves are not specifically attestedto in certain configurations. Note that many different techniques may beused for identity and data integrity attestation, and that the specifictechniques shown herein are merely examples for a better understandingof the role and responsibilities of attestation server 1510.

With reference still to FIG. 15 , as well as the communication exchange1600 as shown in FIG. 16 between the devices of the attestation serviceenvironment 1500 as shown in FIG. 15 . An illustrative process forattestation herein starts with an attestation request 1550. Generally,any device within the system 1500 can initiate the attestation request1550, such as the storage server 420, the source device 410 (e.g.,sending the attestation request to the storage server 420 to thenforward to the attestation server 1510, or else directly to theattestation server 1510), or the particular recipient device 430. In onespecific embodiment, the controller device 440 specifically initiatesthe attestation request, such as to request that the storage server 420(or in alternative embodiments, that the source device 410) obtain asigned certificate 1560 (described below) for the source data 415 froman attestation server 1510, the signed certificate thus allowing averifying recipient device 1530 to confirm that the source data has beenattested to by the attestation server 1510. The verifying recipientdevice 1530 (which, notably, can also initiate the attestation request),may be any device that receives the attestation results from theattestation server, as described below (e.g., a signed certificate, aconfirmation message, etc.). In one illustrative embodiment, forinstance, the controller device 440 is a bank requesting attestation ofa user's identity information (within source data 415) at the sourcedevice 410, and will receive the attestation (without accessing thesource data 415) as the “verifying recipient device” 1530, accordingly.In another illustrative embodiment, for instance, the verifyingrecipient device 1530 may be a government agency requesting attestationof a user's identity information (within source data 415) at the sourcedevice, where the government agency device may (though need not be) be aparticular recipient device 430, as described above.

As an example, a user may enter his/her identity information (e.g., KYCinformation) as source data 415 at the source device 410 (e.g., througha zero-knowledge data management application/process 248). The sourcedevice 410 may then log into a controller device 440 to open an account(e.g., a bank account), and since the source data 415 is intended to bekept in secret from the controller device, the source device (e.g., theapplication 248) or the controller device may inform the storage server420 that a new user is trying to open an account, and that anattestation to the identity of the user is needed (i.e., the source data415). Notably, collection of the source data 415 may be generalized(e.g., the source device collects the data to share generally with otherdevices as requested), or else the collection may be specificallydirected by other devices, such as the attestation server 1510, thecontroller device 440, or any other verifying recipient device 1530.That is, the source device may receive instructions from any of thesedevices to collect the source data, either generally or in responsespecifically to an attestation request 1550.

The attestation server 1510 shares its public key 1511, either to thesource device 410 directly or else to the storage server 420 who canthen share it with the source device. Alternatively, the attestationserver public key 1511 may be shared with the source device 410 by anyother method, including by being publicly known. Note that the sourcedevice may already have the attestation server's public key 1511 priorto the attestation request 1550, or else may receive it in response tothe attestation request (e.g., the storage server connects with theattestation server 1510 and obtains the attestation server's publicencryption key, to then share it with the source device).

At this point, the storage server 420 may either already have thesource-encrypted source data 417, or else the source device 410 mayencrypt the source data 415 and provide the storage server 420 with thesource-encrypted source data, as described above—that is, treating theattestation server as a particular recipient device 430 as describedabove. Here, the source device 410, in response to the attestationrequest 1550 (and in certain embodiments, thus receiving the attestationpublic key 1511) establishes an attestation-server-based rekeying key1518 through an encrypting combination of the source decryption key 412of the source device and the attestation server public key 1511 (e.g.,similar to Eq. 6 and FIG. 6B above). Accordingly, by sending theattestation-server-based rekeying key 1518 to the storage server 420,and in response to the attestation request 1550 received at the storageserver (i.e., a request to share the source data 415 with theattestation server 1510), the storage server re-encrypts (e.g., iscaused to re-encrypt) the source-encrypted source data 417 with theattestation-server-based rekeying key 418, where, just as describedabove for recipient devices (e.g., similar to Eq. 7 and FIG. 6C above),the re-encrypting results in the source data 415 being encrypted withthe attestation server public key 1511 (attestation-server-basedencrypted source data 1527). Note still that the storage server isunable to decrypt the source data encrypted with the attestation serverpublic key (i.e., attestation-server-based encrypted source data 1527).

The storage server 420 may then send the attestation-server-basedencrypted source data 1527 to the attestation server in response to theattestation request 1550. Notably, the specific attestation request 1550for source data 415 may be associated with a trackable identifier (ID)1555 in order to coordinate the attestation to the source data. That is,the ID pairs the request 1550 (and also a signed certificate, describedbelow) with the source data 415 (and thus source-encrypted source data417) (as described in more detail with reference to FIGS. 17A-17Bbelow). In accordance with one specific embodiment, the trackableidentifier (ID) 1555 may be a hash function of the source data 415 or inanother embodiment a hash function of the encrypted source data 417 (asdescribed below).

Once the attestation server 1510 receives the source data encrypted withthe attestation server public key (attestation-server-based encryptedsource data 1527) from the storage server 420, then the attestationserver applies its private key to obtain and process the user's identityinformation from the previously encrypted source data (i.e., decryptingthe attestation-server-based encrypted source data 1527 using anattestation server private key 1512 of the attestation server).

The attestation server 1510 may now view, verify, and attest to thedecrypted source data 415 (e.g., to the personally identifyinginformation (PII), or else to the data integrity in other examplesmentioned herein), using various attestation techniques. For example,PII may be attested to based solely on the source data (e.g.,documentary verification) or else on greater information (e.g.,non-documentary verification). For example, a communication may beestablished between the source device 410 and the attestation server1510, where the attestation server is configured to attest to the PIIbased on the source data and user interaction via the establishedcommunication (e.g., webcam verification, real-time question answering,etc.). Any suitable attestation technique may be used herein, and thosementioned above are merely example embodiments for illustration.

Assuming the data is verified by the attestation server (e.g., manually,autonomously, and/or autonomously with manual assistance), then theattestation server 1510 creates a signed certificate 1560 signifying(acknowledging) the attestation to the source data 415. The attestationcontents 1565 of the certificate may be anything from a simple“verified” indication, an attestation score, a report of what is beingattested to (e.g., “this certifies that user ID #12345 has acceptablyprovided their identity on this date”), and so on. In particular,according to the techniques herein, the attestation server 1510 createsa signed certificate 1560 (based on attesting to the source data) thatwould allow a verifying recipient device 1530 to confirm that the sourcedata 415 has been attested to by the attestation server based on thesigned certificate (i.e., without accessing/decrypting thesource-encrypted source data). (As noted below, in accordance with onespecific embodiment, the signed document 1560 may include the hashfunction of the source data 415 and the verification indication.) In oneembodiment, similar to digital signature techniques, the attestationserver 1510 signs its verification message (signing the signedcertificate) by encrypting the verification message (attestationcontents 1565) by its own private key (attestation server private key1512). This message can then be decrypted by any verifying recipientdevice with knowledge of public key 1511 of the attestation server(which is known to everyone as it is public). Said differently, theverifying recipient device is caused to confirm that the source data 415has been attested to by the attestation server 1510 based on applyingthe attestation server public key 1511 to the signed certificate 1560.Since the public key of the attestation server decrypts the message1560, it is proof that only the attestation server 1510 (the only entitythat knows the attestation server's private key 1512) could have writtenand signed this verification message.

Note also that various other digital signature techniques may also beapplied, such as including a time of the signature, or, moreparticularly, a computed hash of source data 415 within the verificationmessage (certificate 1560), which ensures that the source data has notbeen tampered with, as the signature is mathematically bound to thesource data 415 that it originally was made with (i.e., verificationwill fail for practically any other data, no matter how similar to theoriginal data). Due to the encrypting and re-encrypting of thetechniques herein, however, certain specific embodiments of establishingand using hashes are provided herein. In particular, while a hash can becomputed by the storage server 420 (or source device 410) for thesource-encrypted source data 417, no other device in the system hereinis configured to obtain this data, and only receives recipient-basedencrypted source data 427, or no data (e.g., third-party devices orcontroller devices). As such, this type of hash may be useful toidentify the attestation requests and responses between the storageserver and the attestation server 1510, but not to confirm that thesource data is the original source data. To alleviate this concern, inyet another embodiment, the hash function that is used in thecertificate may be generated by the source device 410 from the raw inputsource data 415. In yet another embodiment, both hash functions (hash of415 and hash of 417) may be used.

FIGS. 17A-17B illustrate simplified block diagrams 1700 a-b of examplesof creating and managing signed certificates 1560, in conjunction withthe discussion of FIGS. 15-16 , and particularly with regard to themanagement of tracking attestation according to the techniques herein.In particular, as shown in FIG. 17A, the source data 415 is encryptedinto source-encrypted source data 417, and an ID 1555 may be establishedby the storage server 420, such as a conventional ID or else a hash ofthe source-encrypted source data for more precise correlation. Inaccordance with another embodiment, the ID is a hash function of the rawdata 410 and is generated by the source device 410, and passed alongfrom the source device 410 to the storage server 420. Note that the ID1555 may also be based on an identifier originating at the controllerdevice 440 (or other device requesting attestation, such as the sourcedevice 410 or particular recipient device 430), or based on a hash ofthe source-encrypted source data as first computed by the source device.When an attestation request is received, the storage server then sendsthe request 1550, along with the attestation-server-based encryptedsource data 1527 and the associated ID 1555 to the attestation server1510. The attestation server uses its private key 1512 to decrypt theencrypted source data 1527, and once verified (attested to), then theresponse (e.g., signed certificate 1560) may also be associated with thecorresponding ID 1555. In particular, since neither the source-encryptedsource data 427 nor the attestation-server-based encrypted source data1527 need be returned from the attestation server, the ID 1555 helps thestorage server to associate the attestation 1560 with the appropriatesource data 415 (that is, associated with the source-encrypted sourcedata 417 currently encrypting the source data at the storage server).(Note that in one or more embodiments herein, rather than using acorresponding ID 1555, the system can use the whole encrypted data inthe attestation certificate 1560—however, the use of an ID such as ahash function reduces the size of the transmitted information and assuch is a more efficient use of system resources.)

Said differently, the attestation server 1510 may create a new document(file) 1560 which includes a) the ID 1555 (e.g., a hash function) whichit received from the storage server 420 (serving as an ID of theencrypted source data in the storage server), as well as b) anattestation statement such as “verified” (or “not valid”). Theattestation server 1510 encrypts the whole document/file (which includesitems a and b from above) with its private key 1512. The ID 1555 mayalso be returned external to the file (signed certificate) 1560 in orderto be used by the storage server 420 for its association with thecorresponding encrypted source data. Now, anyone who has access to thepublic key 1511 of the attestation company can receive the signedcertificate 1560, along with the ID/hash 1555, decipher it, and see thatit must have been the attestation server 1510 that wrote the attestationstatement for the data associated with the ID/hash 1555 (i.e.,confirming that the source data 415, whether visible or not, correspondsto the signed certificate 1560). In accordance with yet another specificembodiment, the corresponding ID 1555 may be encrypted with the publickey 411 of the storage server 420, where this encryption would thusprevent any unauthorized device from gaining access to the internalnumbering used by the storage server.

For instance, by sharing the signed certificate 1560 from theattestation server 1510, this causes a verifying recipient device 1530(e.g., the controller device 440, particular recipient device 430, orother device) to confirm, based on the signed certificate (e.g., withouthaving access to source data 415, or without being able to decrypt anysource-encrypted source data or any recipient-based encrypted sourcedata), that the source data 415 has been attested to by the attestationserver. Note that the signed certificate 1560 may be returned to thestorage server 420, or else may be sent by the attestation server 1510directly to the requesting device or other device as so directed (e.g.,source device 410, recipient device 430, controller device 440, etc.).For instance, where the source device 410 requested or triggered theattestation in certain embodiments, the attestation server may reply tothe source device with the signed certificate 1560 to cause the sourcedevice to send the signed certificate to a verifying recipient device.On the other hand, when returning the signed certificate to the storageserver (e.g., particularly so that the storage server 420 can be incontrol of the certificate, reducing the exposure of the source device410 from being compromised), the storage server associates the signedcertificate 1560 with the source-encrypted source data 417 (e.g., basedon the ID/hash 1555), and can then send the signed certificate to averifying recipient device 1530 in due course (e.g., controller deviceas requested, recipient device as a matter of policy or as requested,etc.). In other words, the storage server 420 now has a) verificationthat the specific source data 415 (e.g., KYC information) correspondingto a specific transaction ID 1555 has been verified by the attestationserver 1510, and b) the source data 415 (e.g., user's KYC data), whichcorresponds to that transaction ID 1555, encrypted with the sourcedevice's public key 411, and can distribute them according to thetechniques described herein. (That is, the storage server knows that thesource data is verified, but does not know what the source data is.)

FIG. 17B illustrates an alternative or additional embodiment to FIG. 17Aabove. In particular, to provide even greater assurance that the sourcedata 415 is the original source data to any endpoint with access to thesource data (i.e., generally only the particular recipient devices 430and attestation server 1510), the source device 410 may compute a hash1755 of the original source data 415, and may include that hash alongwith the source-encrypted source data 417. Now, any device that decryptstheir recipient-based encrypted source data 427 (or 1527) can computetheir own hash of the source data 415 and compare the result with thehash 1755 to confirm that the source data 415 is original. (Theadditional ID/hash 1555 may also still be used for devices to confirmthat the attestation 1560 corresponds to the source data 415.)

Notably, in certain embodiments herein where source data 415 comprisestwo or more sets of data associated or bound together, as mentionedfurther above with reference to FIG. 8B (where each of the associatedsets individually requires a respective rekeying key to be decrypted),the attestation server 1510 herein may be configured to correspondinglyattest to only a particular one of the two or more sets of data. Forinstance, as shown in FIG. 18 (1800), source-encrypted source data417(a) and source-encrypted source data 417(b) may be associatedtogether, namely, their re-encrypted versions 427(a) and 427(b), asdescribed above, and sent together as a package of data (e.g., with hash490), where the recipient “A” is the attestation server 1510, and therecipient “B” is some other device that will be receiving the sets ofdata next). Upon receipt of the associated attestation-server-basedencrypted source data 427(a), the attestation server 1510 is thus onlyable to decrypt that portion of the source data 415(a) (e.g., personallyidentifying information), attest to it, and then may include the hash490 of the associated data sets 427(a) and 427(b) within the signedcertificate 1560. Now, when the sets of data are sent to the secondrecipient device 430(b) (e.g., from the attestation server serially, orelse from the storage server 420 after being processed by theattestation server), the second recipient device may only be able todecrypt and process its portion of the data 427(b), but can see that thefirst portion 415(a) has been attested to by the attestation server viathe signed certificate. An example implementation where this could beuseful is where the attestation server 1510 is also a processor of thesource data 415(a), such as a payment processor accepting payment forgoods or services that are kept secret within source data 415(b) (i.e.,the attestation server/payment processor does not know what is beingpaid for), to then attest to the payment in order to prompt for deliveryof the goods or services by the second recipient device 430(b) (e.g.,where the second recipient device need not or should not know thepayment details or identity information of the payer). Other suitableexamples can of course be implemented using this particular embodimentof the techniques herein, and the one discussed herein is merely onepossible illustration.

Note that FIG. 19 illustrates an alternative embodiment 1900 to thegenerally “storage server directed” attestation techniques describedabove where the source device 410 requests the signed certificate 1560for the source data 415 from the attestation server 1510 directly, andincludes the signed certificate along with the source data in thesource-encrypted source data 417. In this manner, the source-encryptedsource data 417, and thereby also the recipient-based encrypted sourcedata 427, contain the signed certificate 1560. The recipient device 430then obtains the signed certificate 1560 upon decrypting therecipient-based encrypted source data 427 (along with obtaining the rawsource data 415), and can thus confirm that the source data has beenattested to by the attestation server based on the signed certificate,accordingly. (Similar to above, the source data may also be associatedwith a hash value 1755 that is also contained within the signature 1560in order to further confirm that the source data is the data beingattested to.) Note that in certain embodiments, such as the bank accountexample above, it may be imperative that attested information within thesource data be verified without decryption of the source data (e.g.,ensuring that the storage server 420 or bank/controller device 440 canverify that a user's KYC data was attested to prior to opening anaccount with the bank). In other embodiments, on the other hand, it maybe helpful for a particular recipient device 430 to confirm, upondecrypting the source data 415, that the source data has been attestedto by an attestation service (e.g., proof that the data, or at least aportion of the data (e.g., authorship, metadata, etc.) is verifiablycorrect.

In addition, according to one or more embodiments of the presentdisclosure, the signed certificates 1560 may be obtained in advance ofany need, or otherwise stored at the storage server 420 for futureusage, and may actually be stored for a length of time that is longenough to surpass a key rotation event of the attestation server 1510.As noted above, once a key rotation event occurs (i.e., updating theattestation server private key from an original attestation serverprivate key 1512_t to an updated attestation server private key1512_t+1, and also updating the corresponding attestation server publickey from an original attestation server public key 1511_t to an updatedattestation server public key 1511_t+1), then where the certificate 1560(e.g., 1560 t) is signed with the original attestation server privatekey 1512_t, attempting to use an updated attestation server public key1511_t+1 (which is the key verifying recipient devices 1530 would havefor the attestation server at time t+1) to decrypt and verify the signedcertificate would be ineffective. As such, the techniques herein alsoprovide for the establishment, by the attestation server 1510, of anattestation server re-encryption key 1533 through an encryptingcombination of the original attestation server public key 1511_t and theupdated attestation server private key 1512_t+1.

For instance, assume that the signed certificate 1560_t (“Signed Cert”)is created with the attestation contents 1565 (“Attestation”) and theoriginal attestation server private key (1512_t) (“Att Pri”) as follows,and as shown in FIG. 20A:

Attestation (1565)*Att Pri (1512_t)=>Signed Cert (1560_t)  Eq. 17.

Accordingly, a verifying recipient device 1530 would decrypt the signedcertificate 1560_t using the attestation server public key 1511_t (“AttPub”) as follows, and as shown in FIG. 20B:

$\begin{matrix}{{{Signed}{Cert}\left( {1560{\_ t}} \right)*{Att}{Pub}\left( {1511{\_ t}} \right)} = {{\left( {{Attestation}(1565)*{Att}{Pri}\left( {1512{\_ t}} \right)} \right)*{Att}{Pub}\left( {1511{\_ t}} \right)} = {{{Attestation}(1565)*\left( {{Att}{Pri}\left( {1512{\_ t}} \right)*{Att}{Pub}\left( {1511{\_ t}} \right)} \right)} = {{{Attestation}(1565)*(1)} = {> {{Attestation}{(1565).}}}}}}} & {{Eq}.18}\end{matrix}$

However, since after time t+1 the verifying recipient device would havethe updated attestation server public key 1511_t+1, the signedcertificate 1560_t could no longer be decrypted by the verifyingrecipient device. To address this, the techniques herein thus establishthe attestation server re-encryption key 1533 that can be applied to thestored signed certificate 1560_t to make it valid after time t+1.Namely, as mentioned above, the attestation server re-encryption key1533 (“Att Re-Encrypt Key”) may be established by the attestation server1510 through an encrypting combination of the original attestationserver public key 1511_t and the updated attestation server private key1512_t+1, as follows and as in FIG. 20C:

Att Pub (1511_t)*Att Pri (1512_t+1)=>Att Re-Encrypt Key (1533_t+1)  Eq.19.

The attestation server 1510 may then send the attestation serverre-encryption key 1533_t+1 to the storage server 420 to cause thestorage server to apply the attestation server re-encryption key to thesigned certificate 1560_t to generate an updated signed certificate1560_t+1 that is signed with the updated attestation server private key1512_t+1, as shown below and in FIG. 20D:

$\begin{matrix}{{{Signed}{Cert}\left( {1560{\_ t}} \right)*{Att}{Re} - {Encrypt}{Key}\left( {{1533{\_ t}} + 1} \right)} = {{\left( {{Attestation}(1565)*{Att}{Pri}\left( {1512{\_ t}} \right)} \right)*\left( {{Att}{Pub}\left( {1511{\_ t}} \right)*{Att}{Pri}\left( {{1512{\_ t}} + 1} \right)} \right)} = {{{Attestation}(1565)*\left( {{Att}{Pri}\left( {1512{\_ t}} \right)*{Att}{{Pub}\left( {1511{\_ t}} \right)}} \right)*{Att}{Pri}\left( {{1512{\_ t}} + 1} \right)} = {{{Attestation}(1565)*(1)*{Att}{{Pri}\left( {{1512{\_ t}} + 1} \right)}} = {{{Attestation}(1565)*{Att}{Pri}\left( {{1512{\_ t}} + 1} \right)} = {> {{Signed}{Cert}{\left( {{1560{\_ t}} + 1} \right).}}}}}}}} & {{Eq}.20}\end{matrix}$

Now, for any device receiving the updated signed certificate 1560_t+1,application of the attestation server's updated public key 1511_t+1would properly decrypt and verify the attestation (i.e., the verifyingrecipient device is caused to confirm that the source data 415 has beenattested to by the attestation server 1510 based on applying the updatedattestation server public key 1511_t+1 to the signed certificate1560_t+1) as follows, and as shown in FIG. 20E:

$\begin{matrix}{{{Signed}{Cert}\left( {{1560{\_ t}} + 1} \right)*{Att}{Pub}\left( {{1511{\_ t}} + 1} \right)} = {{\left( {{Attestation}(1565)*{Att}{Pri}\left( {{1512{\_ t}} + 1} \right)} \right)*{Att}{Pub}\left( {{1511{\_ t}} + 1} \right)} = {{{Attestation}(1565)*\left( {{Att}{Pri}\left( {1512 + t + 1} \right)*{Att}{Pub}\left( {{1511{\_ t}} + 1} \right)} \right)} = {{{Attestation}(1565)*(1)} = {> {{Attestation}{(1565).}}}}}}} & {{Eq}.21}\end{matrix}$

(Note that as described in greater detail above, the attestation 1565may also include an ID 1555 such as a hash 1755 to allow the verifyingrecipient device 1530 to confirm that the source data 410 corresponds tothe attestation 1565, accordingly.)

As an overall simplified example herein, FIG. 21A illustrates an exampleimplementation of an overall zero-knowledge data management system 2100that may be established according to the techniques described above.(Note that other implementations and configurations are possibleaccording to the techniques herein, particularly the deviceinterconnects and the order of events described below, and the system2100 and the below discussion of one available execution according tocertain embodiments herein is not meant to limit the scope of thepresent disclosure.) For instance, according to an example sequence ofevents, a “zero-knowledge app” 2110 (e.g., source device 410) may beinstalled and operates on a user's device(s) such as a user's mobiledevice. The zero-knowledge app 2110 interacts with the user and obtainsthe user's identity/PII information (e.g., source data 415), which maythen be shared in its enciphered (i.e., encrypted) state 2117 to bestored at “zero-knowledge services” 2120 (e.g., source-encrypted sourcedata 417 at storage server 420), which may also contain other backendservices and systems. Note again that the zero-knowledge services 2120does not (and cannot) gain access to the source data 415 (e.g., to knowthe identity of the user) since it received only the source-encryptedsource data 417 (e.g., the identity information is encrypted).

In particular embodiments herein, certain recipient-based rekeying keys2118 (e.g., recipient-based rekeying keys 418) may need to be generatedand stored prior to receiving a request to share the source data, suchas, e.g., obtaining the rekeying keys at substantially the same time asthe source-encrypted source data 417 (enciphered PII 2117). For example,the rekeying key for an attestation service may be required immediately,and other rekeying keys, which may not be used until a later time, maystill need to be obtained up-front, such as for government reporting ata later time (e.g., in order to protect against the scenario where thegovernment requests a report where at the same time the source device nolonger exists or has already deleted the zero-knowledge data managementapplication).

Continuing with the example in FIG. 21A, assume that the user accesses abank's user interface at a “zero-knowledge partner” device 2140 (e.g.,controller device 440) to open a new bank account. As discussed above,the partner 2140 may be an entity that does not want to (or should not)store or access the user's identity information. So before the accountcan be opened, the user's identity must be verified and attested to bythe identification verification (IDV) provider 2170 (e.g., attestationserver 1510), in order to ensure that the user is who they say they are,and that who they say they are is not associated with any prohibited orcautionary list of users (e.g., criminals, terrorists, politicallyexposed person, etc.). In response to a request for the attestation(e.g., originating from the app 2110 or else from the centralizedzero-knowledge services 2120), the zero-knowledge services 2120 may thenre-encrypt the user's stored identity information, and sends it to theIDV provider 2170 to decrypt and attest to the identity, accordingly(e.g., security questions, webcam comparison of user's live image to apassport photo, etc.). (Note again that the rekeying key for the IDVprovider may be generated and obtained in advance of the request forattestation, i.e., along with the production of the source-encryptedsource data 417.) The IDV provider 2170 can then accredit/attest to theuser's approved identity (or may disapprove it), and creates a signedcertificate as described above for consumption by the bank (partner2140) to allow the bank to open the account without the bank everknowing the user's real-life identity or related PII (that is, the bankhas no idea who the user actually is, just that they are who they saythey are). (Note that the signed attestation certificate may also bestored with the user's identity information as well, as describedabove.) An identification number (e.g., account number or otherwise,such as an internal number or ID) may then be shared with thezero-knowledge services 2120 to correlate the user's enciphered identitydata to the bank's records of the account.

Based on the interaction being with a bank, either at the request of thebank (partner 2140) or at the configuration of zero-knowledge services2120, the zero-knowledge app 2110 creates the rekeying key 2118 for anillustrative regulatory reporting provider 2130 (e.g., particularrecipient device 430), such as contemporaneously with generation of thesource-encrypted source data 2117 (e.g., for eventual sharing with knownrecipients), or else afterward (e.g., only once a specific request ismade to share with a particular recipient). Note that the regulatoryreporting provider 2130 (or an “intermediate reporting service” 2130,generally) may act as legal agents to fulfill regulatory reportingrequirements (e.g., deciphering the enciphered data to completeregulatory forms, such as particular FinCEN forms), to then deliver suchreports to the government regulator 2180 (e.g., FinCEN) to actuallyregulate the financial activities (e.g., sent between these two devicesusing standard encryption techniques). Alternatively, the ultimateparticular recipient device for which a rekeying key is needed may bethe government regulator 2180. That is, the regulatory reportingprovider 2130 may only be used as an intermediate device that correlatesthe bank's information to the enciphered identity data that can bepassed to, and only read by, the government regulator, accordingly.

For instance, assume that in the course of the bank's user interfaceperforming its “identity-less” functions (e.g., checking balances,transferring money, and so on based on an account number and associatedpassword or other identifying token associated with the account number,and not based on any real identity information such as PII) with theuser at zero-knowledge app 2110, that a currency transaction report(CTR) is triggered based on a large (e.g., greater than $10,000)transfer by the user. At this time, the bank 2140 may request that thezero-knowledge services 2120 provide the user's identity information tothe government by sending the user's identification number (e.g.,account number or other internal number or ID value) to zero-knowledgeservices 2120, which can then re-encrypt the user's enciphered identitydata into an enciphered format that can now be read only by theregulatory reporting provider 2130, or alternatively, only by thegovernment regulator 2180. (Note that in the former embodiment, theregulatory reporting provider may be configured to delete or otherwisenot store any identity data after generating and sending the report tothe government.)

In this manner, the user's verified identity is protected, visible onlyto the IDV provider (which may delete/not store the identity info afterit is attested to) and the government regulator in response totriggering events, without hindering the operation of the rest of thesystem 2100 (e.g., typical banking functionality).

Additionally, FIG. 21B illustrates a specific (and simplified) example2100 b of an intermediate reporting service 2130 according to an examplezero-knowledge data management system herein. Namely, a first set ofdata or information 2147 may be generated in any number of ways, such asby a partner device 2140 (e.g., controller device 440), zero-knowledgeservices 2120 (e.g., storage server 420), IDV provider 2170 (e.g.,attestation server 1510), or any other suitable device (e.g., as shownin FIG. 21A above). For example, the first set of data 2147 maygenerally be based on a particular transaction (e.g., financialtransaction or otherwise). The device generating and sharing the firstset of data/information 2147 intends on the data reaching theintermediate reporting device 2130 in a manner readable by theintermediate reporting device, such as by directly sending the set ofinformation to the intermediate reporting device, or else by sending theset of information to a zero-knowledge services 2120 (e.g., storageserver 420) to cause the set of information to be sent to theintermediate reporting device (e.g., as encrypted information, such asin accordance with the zero-knowledge data management techniques above).Said differently, the first set of data 2147 may be encrypted as it isbeing transmitted towards the reporting device 2130, and/or may berecipient-based encrypted source data (427) readable only to thereporting device, in a manner as described above.

In addition to receiving the first set of data 2147 (readable by theintermediate reporting device 2130), the intermediate reporting device2130 also receives a second set of data 2127 that is generallyunreadable by the intermediate reporting device (e.g., it is encryptedby a public key of a second recipient device, or more particularly, isthe recipient-based encrypted source data 427 described above, where theultimate recipient device 430 is serially next-in-line to the reportingdevice 2130, as described below). Note that in one embodiment, asdescribed above, the second set of data 2127 may be associated with anattestation (e.g., digital signature 1560) in response to the sourcedata within the recipient-based encrypted source data being attested toby an attestation server 1510.

By reading the first set of data 2147 (e.g., decrypting encrypted datausing a private key of the intermediate reporting device to obtain theactual data), the intermediate reporting device 2130 may then create areport 2160 based on first set of data, according to a variety ofreporting configurations. For example, FinCEN forms or other regulationforms may be filled in (e.g., partially) using the information, or otherconclusive reports may be generated based on processing the information.According to the techniques herein, the intermediate reporting device“packages” the second set of data 2127 with the report 2160 (e.g.,associates them, includes one as an attachment to the other, and so on),where the reporting device may still be unable to read the second set ofdata 2127. By then sending the packaged report and second set of data(2160/2127) to a second recipient device, e.g., particular recipientdevice 430 (notably where the second set of data is readable by thesecond recipient device), then the second/recipient device is able to(e.g., is caused to) read (e.g., decrypt) the second set of data andprocess the report with the second set of data, accordingly. (Note thatthe second/recipient device 430 need not be privy to the first set ofdata but only what it contained within the report 2160, and in someembodiments may actually be prevented from reading the information—e.g.,receiving a summary of the information within the report.) For instance,in an embodiment where the report 2160 is a currency transaction report(CTR), a government regulator 2130 may receive the report 2160 based onthe bank's financial transaction information 2147 (e.g., account numbersof transferee and transferor, amount, time, etc.) and can then decryptthe secured transfer of data 2127 to obtain the associated user'sidentity/PII (decrypted source data 415) for processing. (Note that theidentity of both transferee and transferor may also be included, and assuch the correlation within the report may use two separate pieces ofinformation 2127 triggered by the transaction.) Of course, otherexamples of intermediate reporting systems and methods may be usedherein, and those described above, particularly as they pertain togovernmentally regulated activities, are merely examples.

In closing, FIGS. 22A-22C illustrate an example simplified procedure forzero-knowledge data management in accordance with one or moreembodiments described herein, particularly from the perspective of astorage server 420. For example, a non-generic, specifically configureddevice (e.g., storage server 420) may perform procedure 2200 byexecuting stored instructions (e.g., zero-knowledge data managementprocess 248). The procedure 2200 may start at step 2205, and continuesto step 2210, where, as described in greater detail above, the storageserver obtains (e.g., receives) source-encrypted source data 417 from asource device 410, the source-encrypted source data comprising sourcedata 415 encrypted by the source device with a source encryption key 411of the source device (e.g., a public key). As described above, in thiscombination, the source device has complete control over who is able todecrypt the encrypted source data, notably where the storage server isunable to decrypt the source-encrypted source data. Also, in step 2215,the storage server stores the source-encrypted source data.

In step 2220, the storage server also obtains (e.g., receives), andstores, a recipient-based rekeying key 418 from the source device, therecipient-based rekeying key established through an encryptingcombination of a source decryption key 412 of the source device (e.g., aprivate key) and a recipient public key 431 of a particular recipientdevice 430. In one embodiment, the storage server may have firstinformed the source device of the recipient public key of the particularrecipient device, such as, e.g., sharing the recipient public keyspecifically in response to receiving a request to share the source datawith the particular recipient device (step 2240 below). Note also thatthe recipient-based rekeying key 418 may be obtained contemporaneouslywith obtaining the source-encrypted source data from the source devicein step 2210, or else may be obtained contemporaneously with receivingthe request to share the source data with the particular recipientdevice (step 2240 below), and the order of the steps shown is merely oneexample implementation.

In the event that the recipient device updates its public/private keypair (431/432) in step 2225 at any point in time after the storageserver has received the recipient-based rekeying key 418 (i.e., inresponse to an updated recipient public key of the particular recipientdevice and corresponding updated recipient private key), then in step2230 the storage server may receive, from the particular recipientdevice, a recipient re-encryption key 433. In particular, the recipientre-encryption key 433 may be established through an encryptingcombination of an original recipient private key 432_t of the particularrecipient device and the updated recipient public key 431_t+1, asdescribed in greater detail above. Notably, step 2230 may occur as apush from the recipient device 430, or else may be in response to arequest from the storage server to compute and return the recipientre-encryption key 433, e.g., in response to detecting an updated publickey from the recipient device. Accordingly, in step 2235, the storageserver may then apply the recipient re-encryption key 433 to therecipient-based rekeying key 418 (418_t) to generate an updatedrecipient-based rekeying key 418_t+1 that is an encrypting combinationof the source decryption key 412 and the updated recipient public key431_t+1.

In addition, in the event that the source device updates itsencryption/decryption (e.g., public/private) key pair (411/412) in step2240, particularly at any point in time after the storage server hasstored the source data 415 or received a recipient-based rekeying key418, then in step 2245, in certain embodiments (e.g., where the storageserver is involved other than merely receiving updated source data orrekeying keys based on original decryption keys), the storage server mayreceive, from the source device 415, a source data re-encryption key 419established through an encrypting combination of an original sourcedecryption key 412_t and the updated source encryption key 411_t+1.Accordingly, in step 2250, the storage server may then apply the sourcedata re-encryption key 419 to the source-encrypted source data 417_t togenerate an updated source-encrypted source data 417_t+1 that is thesource data 415 encrypted by the updated source encryption key 411_t+1.Note also that as part of step 2250, as noted above, the source devicemay also send the storage server follow-on updates in response toupdating the source-encrypted source data, such as where originalrecipient-based rekeying keys 418_t, stored at the storage server, wereestablished through an encrypting combination of the original sourcedecryption key and a recipient public key of a respective recipientdevice. In particular, to ensure proper key pairing, in one embodimentthe storage server may receive, from the source device, updatedrecipient-based rekeying keys 418_t+1 to replace the originalrecipient-based rekeying keys 418_t, where the updated recipient-basedrekeying keys 418_t+1 are established through an encrypting combinationof an updated source decryption key 412_t+1 and the recipient public key431 of a respective recipient device 430, as described above. In anotherembodiment, the follow-on update in step 2250 may comprise receiving,from the source device, a source-based re-encryption key 413 for each ofthe one or more original recipient-based rekeying keys 418_t, eachsource-based re-encryption key 413 established through an encryptingcombination of an original source encryption key 411_t and the recipientpublic key 431 of a respective recipient device. The storage serverwould then apply the source-based re-encryption key 413 for each of theone or more original recipient-based rekeying keys to the one or moreoriginal recipient-based rekeying keys 418_t to generate an updatedrecipient-based rekeying key 418_t+1 to replace each of the one or moreoriginal recipient-based rekeying keys (i.e., being an encryptingcombination of the updated source decryption key 412_t+1 and therecipient public key 431 of a respective recipient device).

According to the techniques described herein, the storage server 420 mayreceive, in step 2255, a request 550 to share the source data with theparticular recipient device 430. As mentioned above, the request toshare the source data with the particular recipient device may bereceived from the source device 410, the recipient device 430, anauthorized controller device 440 (e.g., that is unable to decrypt thesource-encrypted source data or the recipient-based encrypted sourcedata 427), or may be a self-determined request by the storage server 420triggered in response to one or more policies at the storage server(e.g., static or based on behavioral analytics). As also mentionedabove, the request may be received prior to obtaining therecipient-based rekeying key, and the storage server may be configuredto share the recipient's public key in response to the request (to causethe source device to create the recipient-based rekeying key,accordingly). In particular embodiments, however, it may be required togenerate and store certain (e.g., all or only some) recipient-basedrekeying keys at substantially the same time as the source-encryptedsource data to ensure that after a length of time (e.g., a few years)that the source data 415 is still recoverable (e.g., long after a userno longer has an associated application on the source device, it maystill be required to generate reports for the government from thesource-encrypted source data).

In accordance with one or more particular embodiments mentioned above,certain configurations of the zero-knowledge data management systemherein are not based solely on one set of source data for each sourcedevice in the system, but instead may be based on obtaining a pluralityof sets of source-encrypted source data 415(i) from the (or from each)source device 410 (i.e., multiple steps 2210 above). Additionally, thetechniques herein may also comprise obtaining a plurality ofrecipient-based rekeying keys 418 (i.e., multiple steps 2220 above),such as where the system is configured to store recipient-based rekeyingkeys 418 prior to receiving specific requests, where eachrecipient-based rekeying key corresponds to an encrypting combination ofthe source decryption key 412 and a respective recipient public key431(i) of a respective recipient device 430(i) from a plurality ofrecipient devices 430. Accordingly, in step 2255, the received requestto share the source data may specifically indicate the particularrecipient device 430(i) and may also carry an indication of a particularset of source-encrypted source data 415(i) to share. As such, inoptional step 2260, based on the request to share the source data andthe particular recipient device in the request, the storage server mayselect the particular set of source-encrypted source data 415(i) tore-encrypt with the selected recipient-based rekeying key 418(i) (step2275 below).

Note that as described above, one or more of the plurality of recipientdevices in these particular embodiments may comprise a group ofcategorically similar recipients that share a group-based recipientpublic key 418(grp) (e.g., retail, medical, etc.). As also describedabove, two or more sets of source-encrypted source data may beassociated together (e.g., one used for user-identifying information,others used for data other than user-identifying information), whereeach of the associated sets individually requires a respective recipientprivate key to decrypt the corresponding source data once re-encryptedinto recipient-based encrypted source data.

In one embodiment, in step 2265, the storage server may be configured asa secondary level of security, optionally confirming, in response toreceiving the request to share the source data with the particularrecipient device, that the particular recipient device is, in fact,authorized to receive the source data. For example, as mentioned above,the storage server may check the particular recipient device against alist (e.g., whitelist, blacklist, ACL, etc.), and determines whether theparticular recipient device is authorized to receive the source dataaccording to that check. The list itself may specifically be based ondevice identifications (i.e., particular devices), network domains(e.g., address prefixes, URLs, asynchronous system names, etc.),geographical locations, or other authorization policies, and may belocally configured and/or may be based on receiving one or moreentries/policies from controller devices 440. The authorization (i.e.,confirming whether the particular recipient device is authorized toreceive the source data) may also be pairing-based, that is, in additionto policies that apply to particular recipient devices (or domains,etc.) globally (i.e., a recipient itself), combinations factors may beregulated, such as, e.g., a particular source device sending data to aparticular recipient device, a particular source data being sent to aparticular recipient device, and so on. Note further that the listentries and/or policies may be statically configured, or, as describedabove, may have at least a portion of the list that is dynamicallyconfigured, e.g., based on behavioral analytics (e.g., based onobservations across a plurality of source devices, and optionallyreceived from a behavioral analytics server). Moreover, in oneembodiment mentioned above, confirming that the particular recipientdevice is authorized to receive the source data in step 2265 maycomprise requesting and confirming authentication credentials from theparticular recipient device. In step 2270, in response to the particularrecipient device not being authorized to receive the source data, thestorage server may specifically prevent (deny) access by the particularrecipient device to the source data (e.g., preventing the re-encryptingof the source-encrypted source data 417 with the recipient-basedrekeying key 418 and the sending of the recipient-based encrypted sourcedata 427 to the particular recipient device). In certain embodiments,step 2270 may also include responding to the request to share the sourcedata with the particular recipient device with a reason for denial ofthe request (e.g., to whichever device sent the request, and/or isexpecting the request to be completed), or else the request may simplybe ignored.

According to the techniques herein (e.g., assuming the particularrecipient device is authorized to receive the source data), the storageserver 420 re-encrypts the source-encrypted source data 417 in step 2275with the recipient-based rekeying key 418. As detailed above, there-encrypting in step 2275 results in the source data 415 now beingencrypted with the recipient public key 431 of the particular recipientdevice 430 (i.e., recipient-based encrypted source data 427), where,notably, the storage server still is unable to decrypt the source dataencrypted with the recipient public key (recipient-based encryptedsource data 427).

Finally, in step 2280, the storage server sends the source data 415encrypted with the recipient public key 431 (i.e., recipient-basedencrypted source data 427) to the particular recipient device 430 toenable/cause the particular recipient device to decrypt therecipient-based encrypted source data using a recipient private key 432of the particular recipient device to obtain the original source data415, accordingly. Notably, as described above, the source data may besent in a manner that is first handled by an intermediate reportingdevice/server 2130, which may pair a set of transaction-basedinformation with the received recipient-based encrypted source data 427(which the reporting device cannot read) to create a report based on theset of information and the packaged recipient-based encrypted sourcedata for sending to the particular recipient device 430. Also, accordingto other embodiments herein, the source data 415 may comprise aplurality of sets of data that can be decrypted and processed bycorrespondingly different devices (e.g., in parallel or in serial, asdescribed herein).

Notably, in one embodiment mentioned above, the request to share thesource data with the particular recipient device may comprise aparticular identification (e.g., from a controller device that initiatedthe request to share the source data with the particular recipientdevice). When this is the case, the storage server may also include theidentification when sending the source data encrypted with the recipientpublic key (i.e., recipient-based encrypted source data 427) to theparticular recipient device, in order to allow the particular recipientto connect the decrypted source data 415 with a received report 560 atthe particular recipient device having the same identification (e.g.,connecting a CTR from a bank to a particular set of KYC data from auser/source device, such as through a “request identification”).

The procedure 2200 ends in step 2285, notably with the ability tocontinue to receive further source data, updated keys, requests, and soon.

FIGS. 23A-23B illustrate another example simplified procedure forzero-knowledge data management in accordance with one or moreembodiments described herein, particularly from the perspective of asource device 410 (or source application running on a source device or awebsite (web server) configured to collect the source data). Forexample, a non-generic, specifically configured device (e.g., sourcedevice 410) may perform procedure 2300 by executing stored instructions(e.g., zero-knowledge data management process 248 on the source device).The procedure 2300 may start at step 2305 and continues to step 2310,where, as described in greater detail above, the source device obtainssource data 415 (e.g., website cookies, search terms, PII, names,addresses, phone numbers, credit card numbers, bank account numbers,usernames, passwords, pins, social security numbers, files, documents,images, program code, sensed data, and so on). As discussed above, thesource data may be collected according to local direction/control,and/or based on received instructions from a controller device 440 tocollect the source data, or else from an attestation server or verifyingrecipient device.

According to the techniques described herein, the source device may thenencrypt the source data 415 with a source encryption key 411 (e.g.,public key) of the source device to form source-encrypted source data417 in step 2315. In step 2320, the source device 410 may then send thesource-encrypted source data 417 to a storage server 420, where thestorage server is unable to decrypt the source-encrypted source data.(Note that the source device may also compute a hash of the source data,and may include the hash as part of the source-encrypted source data tolater cause a particular recipient device to confirm that the sourcedata obtained at the particular recipient device is the same as thesource data sent from the source device based on matching the hashincluded as part of the source-encrypted source data to a computed hashof the source data computed by the particular recipient device.)Optionally, in one particular embodiment herein, the source device mayalso request a signed certificate 1560 for the source data from anattestation server 1510, which, as described above, would allow aparticular receiving device to confirm that the source data has beenverified and attested to by the attestation server. As such, the sentsource-encrypted source data 417 may include the signed certificate 1560(e.g., encrypted along with the data, or else as a tagalong componentcorresponding to the data).

As previously noted, a plurality of sets of source-encrypted source datamay be sent by the source device to the storage server, such asdifferent sets for different types of recipients (e.g., financial,government, emergency, medical, retail, etc.). Also, two or more sets ofsource-encrypted source data may be associated together (eachindividually requiring a respective recipient-based rekeying key todecrypt the corresponding source data), such as for connectinguser-identifying information in one set with data other thanuser-identifying information in another set, in order to allow differentrecipient devices to view different portions of the related data. Also,as mentioned above, certain recipient devices may be a part of a groupof categorically similar recipients that share a group-based recipientpublic key 431(grp), such as a collection of retail stores, medicalemergency centers, and so on. (For the sake of simplicity, the examplesabove have been discussed using a single source device key pair 411/412.However, the techniques herein also specifically contemplate that thesource device may use multiple key pairs, where each key pair may bedesignated to operate on different data sets (such as the data setsdescribed in FIGS. 8A and 8B, above).)

Note that for optionally added security in one embodiment, in step 2325,the source device may also delete/not store any source data 415 from itsstorage once it is encrypted into the source-encrypted source data 417.

In step 2330, the source device obtains the recipient public key 431 ofa particular recipient device 430 (optionally receiving the key from thestorage server 420, such as a matter of course, or else in response tothe storage server first receiving the request to share the sourcedata).

Accordingly, in step 2335 (as a matter of course or in response to aspecific request to do so), the source device establishes arecipient-based rekeying key 418 through an encrypting combination of asource decryption key 412 (e.g., private key) of the source device 410and a recipient public key 431 of the particular recipient device 430.(As noted above, the source device may use a singleencryption/decryption key pair to encrypt all separate pieces of data,or, in accordance with another embodiment, may use different key pairsto encrypt and re-encrypt different data sets (e.g., keys 411 a/412 a,411 b/412 b, . . . 411 k/412 k for data sets 415 a, 415 b, . . . 415k).) In the event that the rekeying keys are sent only in response to arequest to share the source data, then only that recipient-basedrekeying key is established (and later sent). However, in an alternativeembodiment where the storage server is pre-loaded with a plurality ofrecipient-based rekeying keys (to have ready for a received request toshare), then the source device may establish each recipient-basedrekeying key of the plurality of recipient-based rekeying keys tocorrespond to an encrypting combination of the source decryption key anda respective recipient public key of a respective recipient device froma plurality of recipient devices.

In step 2340, the source device sends the recipient-based rekeyingkey(s) 418 to the storage server. Notably, in one embodiment therekeying key(s) may be sent separately from the source-encrypted sourcedata, however in another embodiment the source device sends thesource-encrypted source data to the storage server (step 2320 above)contemporaneously with sending the recipient-based rekeying key in step2340.

According to one or more optional embodiments herein, the source devicemay update its encryption/decryption key pair for key rotation, namelywhere in step 2345 the source device updates the source encryption(e.g., public) key from an original source encryption key 411_t to anupdated source encryption key 411_t+1, and also updating thecorresponding source decryption (e.g., private) key from an originalsource decryption key 412_t to an updated source decryption key 412_t+1.Assuming, as noted above, that this occurs at any point in time afterthe storage server has stored the source data 415 or received arecipient-based rekeying key 418, then in certain embodiments the sourcedevice may be configured to “update the storage server” in step 2350, ifnecessary.

Illustrative step 2350, in particular, may be based on a number offactors, including configuration of the source device and/or storageserver, the operation of the system in general, and the timing of theupdated key pair in step 2345. In a first embodiment, the source devicemay maintain the original source decryption key 412_t, and correlatesthe original source decryption key to source-encrypted source data 417_tencrypted with the original source encryption key 411_t. As such,whenever establishing additional (e.g., a second or more)recipient-based rekeying keys in the future (i.e., after updating thesource decryption key to the updated source decryption key 412_t+1), therecipient-based rekeying keys are established through an encryptingcombination of the original source decryption key 412_t and a recipientpublic key 431 of a given recipient device 430 (i.e., in response to thesource-encrypted source data 417_t being encrypted with the originalsource encryption key 411_t).

In another embodiment of illustrative step 2350, rather than maintainingold keys and keeping track of which generation is needed forencryption/re-encryption, the techniques herein may update thesource-encrypted source data 417. In particular, as described above, thesource device may simply encrypt the source data 415 (e.g., unchanged,or with updates) with the updated source encryption key 411_t+1 to formupdated source-encrypted source data 417_t+1, sending the updatedsource-encrypted source data to the storage server 420 (still, notably,unable to decrypt the updated source-encrypted source data).Accordingly, establishing additional recipient-based rekeying keys 418after sending the updated source-encrypted source data 417_t+1 to thestorage server may be performed through an encrypting combination of theupdated source decryption key 412_t+1 of the source device and arecipient public key 431 of a given recipient device, as detailed above.

In still a further embodiment of “updating the storage server” in step2350, the source device 410 may establish a source data re-encryptionkey 419 through an encrypting combination of an original sourcedecryption key 412_t and the updated source encryption key 411_t+1, andsends the source data re-encryption key 419 to the storage server tocause the storage server to apply the source data re-encryption key tothe source-encrypted source data 417_t to generate an updatedsource-encrypted source data 417_t+1 that is the source data 415encrypted by the updated source encryption key 411_t+1, as shown ingreater detail above. Note that as part of step 2350 in this furtherembodiment, the source device may also send the storage server follow-onupdates in response to updating the source-encrypted source data, suchas where original recipient-based rekeying keys 418_t, stored at thestorage server, were established through an encrypting combination ofthe original source decryption key and a recipient public key of arespective recipient device. In particular, to ensure proper keypairing, in one embodiment the source device may send the storage serverupdated recipient-based rekeying keys 418_t+1 to replace the originalrecipient-based rekeying keys 418_t (i.e., replacing the originalrecipient-based rekeying keys stored at the storage server with updatedrecipient-based rekeying keys), where the updated recipient-basedrekeying keys 418_t+1 are established through an encrypting combinationof an updated source decryption key 412_t+1 and the recipient public key431 of a respective recipient device 430, as described above. In anotherembodiment, the follow-on update in step 2350 may comprise establishingand sending, from the source device, a source-based re-encryption key413 for each of the one or more original recipient-based rekeying keys418_t, each source-based re-encryption key 413 established through anencrypting combination of an original source encryption key 411_t andthe recipient public key 431 of a respective recipient device. Thiswould then cause the storage server to apply the source-basedre-encryption key 413 for each of the one or more originalrecipient-based rekeying keys to the one or more originalrecipient-based rekeying keys 418_t to generate an updatedrecipient-based rekeying key 418_t+1 to replace each of the one or moreoriginal recipient-based rekeying keys (i.e., being an encryptingcombination of the updated source decryption key 412_t+1 and therecipient public key 431 of a respective recipient device), as detailedabove.

In one embodiment, in step 2355, the source device may optionally be thedevice to send a request to share the source data with the particularrecipient device to the storage server (e.g., based on receivinginstruction from a controller device, or based onsource-device-initiated triggers, such as policy-based events, userrequests, and so on). (Also, as another alternative embodiment to thoseabove, the recipient-based rekeying key 418 may be sent by the sourcedevice contemporaneously with the source device's request to share thesource data.) In other embodiments, other devices initiate the requestto share the source data, such as an authorized controller device 440(notably that is unable to decrypt the source-encrypted source data orthe recipient-based encrypted source data 427), the particular recipientdevice 430, and so on.

As detailed above, a request 550 sent to the storage server 420 to sharethe source data 415 with the particular recipient device 430 causes thestorage server to i) re-encrypt the source-encrypted source data 417with the recipient-based rekeying key 418, the re-encrypting resultingin recipient-based encrypted source data 427 that is the source data 415encrypted with the recipient public key 431 of the particular recipientdevice, where the storage server is unable to decrypt therecipient-based encrypted source data, and ii) send the recipient-basedencrypted source data 427 to the particular recipient device to enable(cause) the particular recipient device to decrypt the recipient-basedencrypted source data using a recipient private key 432 of theparticular recipient device to obtain the original source data 415. Asalso noted above, the storage server may select, based on the particularrecipient device in the request to share the source data, a particularrecipient-based rekeying key of a plurality of recipient-based rekeyingkeys that corresponds to the particular recipient device forre-encrypting the source-encrypted source data. Note, too, that sendingthe request to share the source data with the particular recipientdevice may comprise an indication of a particular set ofsource-encrypted source data to share, such that the storage serverselects the particular set of source-encrypted source data.

The procedure 2300 ends in step 2360. Notably, however, the request toshare the source data could be denied as described above (e.g., therecipient device is not authorized to receive the source data), and assuch the source device may simply receive a reason for denial to therequest (or may have not received the public key of that particularrecipient device or a request to establish the rekeying key for thatrecipient device in the first place), or else the request may simply beignored.

Other procedures relative to zero-knowledge data management, such asfrom the perspective of different participating devices, for when anattestation service is used to attest to the source data, for reportinginformation to a recipient device based on certain triggers, forproviding a secure financial transaction, and so on, are described incommonly owned, co-pending, U.S. patent application Ser. No. 16/703,847,filed on Dec. 4, 2019, entitled SOURCING INFORMATION FOR AZERO-KNOWLEDGE DATA MANAGEMENT NETWORK, by Shockley, et al., nowpublished as US-2020-0184084-A1 on Jun. 11, 2020, the contents of whichbeing incorporated herein by reference in its entirety.

——Using Multiple Devices for Accessing Concealed Information——

FIG. 24 illustrates an alternative example of a concealed informationsystem in accordance with one or more embodiments described herein. Inparticular, a user 2405 of a zero knowledge system uses a first mobileclient 2410. The client has data 2412 that it stores on a zero knowledgeserver e.g., an AVS server 2450. Before storing the data, the clientencrypts the data using its public key PubK1 2416 (e.g., “Src Pub”above). The stored data 2432 (or 2452) can now be described as:

Data*PubK1  Eq. 22a.

As described in greater detail above, the data can then be decryptedusing the private key PriK1 2414 (e.g., Src Pri) of the encryptingdevice:

$\begin{matrix}{{\left( {{Data}*{PubK}1} \right)*{PriK}1} = {{{Data}*\left( {{PubK}1*{PriK}1} \right)} = {{Data}.}}} & {{{Eq}.22}b}\end{matrix}$

A problem arises, however, when the user wants to access the data from anew device, e.g., from device 2420, which has its own private key PriK22424 and public key PubK2 2426. What is needed, therefore, is a systemthat facilitates access to the data from the original device 2410 aswell as from any new device (e.g., 2420 or others) that is owned by thesame person/entity. For example, this would provide access by the sameperson from two devices, by two owners of an account such as husband andwife, business partners, etc.

FIGS. 25A-25C illustrate an example of using multiple devices to accessconcealed information in accordance with one or more embodimentsdescribed herein. Said differently, FIGS. 25A-25C describe a process forsharing access rights from one device/client (e.g., an original device,such as 2410 above) with a new device/client (e.g., device 2420 above).Referring to FIG. 25A, the process starts with operation 2532 where thetwo devices exchange their public keys, PubK1 and PubK2, respectively.Referring now to FIG. 25B in step 2534, the first device 2410communicates to the second device 2420 its private key, PriK1, encryptedby the public key of the second device, PubK2, as well as the originaldata encrypted with its public key:

PriK1*PubK2  Eq. 23a;

Data*PubK2  Eq. 23b.

The second device may then use its private key, PriK2, to decipher boththe private key of the first client and the original data:

PriK1*(PubK2*PriK2)=>PriK1  Eq. 24a;

Data*(PubK1*PriK1)=>Data  Eq. 24b.

The second device can now modify the data, and encrypt it with both thepublic key of the first device and with the public key of the seconddevice and in step 2536 store the result on the zero knowledge servers,such as the AVS server 2450:

Data*(PubK1*PubK2)=>New Stored Data  Eq. 25.

By providing a secured ID of the data, the second device can override(or overwrite) the original data. In one example implementation, thesecond device may also provide a hash function of the original data,e.g., (Data*PubK1), or any other identification method that ensures thatonly an authorized device can override the original data.

Similarly, referring to FIG. 25C and operation 2538, the second devicemay encrypt its private key, PriK2, with the public key of the firstclient, PubK1, and sends it to the first device. The first device maythen use its private key, PriK1, to decipher the private key of thesecond client, PriK2:

PriK2*(PubK1*PriK1)=>PriK2  Eq. 26.

In step 2540, the first device may then retrieve from the zero knowledgeserver 2450 the newly encrypted data which was stored by the seconddevice. The first device can then use the two private keys to decipherthe data and if needed, modify it and store it encrypted with thecombined encrypted public keys PubK1*PubK2 in step 2542:

Data*(PubK1*PubK2)*(PriK1*PriK2)=>Data*(PubK1*PriK1)*(PubK2*PriK2)=>Data  Eq.27a.

New Data*PubK1*PubK2=>New Encrypt.Data  Eq. 27b.

In one example implementation, each time the data is modified the zeroknowledge server notifies the second device/client that the data it hasis stale and it needs to be retrieved from the server before it startsmodifying it. In another example implementation, the data on each deviceis considered to be always staled, and if the user wants to modify thedata, it must be first retrieved from the server, decrypted, and onlythen modified.

In accordance with one or more additional embodiments of the techniquesherein, in order to simplify computations, each device/client may createa new joint/common private key, “PriK1&2”:

PriK1*PriK2=>PriK1&2  Eq. 28a;

and a joint public key, “PubK1&2”:

PubK1*PubK2=>PubK1&2  Eq. 28b.

The devices may then use these joint/common keys for deciphering thedata and then encrypting it before storing it after it has beenmodified.

In closing, FIG. 26 illustrates an example simplified procedure forstoring encrypted data for access by a trusted device in accordance withone or more embodiments described herein, particularly from theperspective of a “first device” (i.e., the device originally storing thedata). For example, a non-generic, specifically configured device (e.gdevice 200) may perform procedure 2600 by executing stored instructions(e.g., process 248). The procedure 2600 may start at step 2605, andcontinues to step 2610, where, as described in greater detail above, afirst device may encrypt data, using a public key of the first device.In step 2615, the first device stores the encrypted data on a storageserver. In step 2620, the first device encrypts a private key of thefirst device into an encrypted private key using a public key of asecond device. In step 2625, the first device communicates the encryptedprivate key of the first device to the second device, where the seconddevice is configured to access the encrypted data on the storage serverbased on decrypting the encrypted private key of the first device byutilizing a private key of the second device and utilizing the privatekey of the first device to access the encrypted data stored on thestorage server.

The simplified procedure 2600 may then end in step 2630. Other steps mayalso be included generally within procedure 2600. For example, suchsteps (or, more generally, such additions to steps already specificallyillustrated above), may include having the second device modify the dataaccessed from the storage server into modified data, encrypting themodified data with the public key of the first device and the public keyof the second device, and storing the modified data on the storageserver. Additional steps may further include receiving a notificationwhen the data is modified by the second device and retrieving the datafrom the sever before remodifying the data in response to thenotification; and so on.

Furthermore, FIG. 27 illustrates an example simplified procedure foraccessing encrypted information with a trusted device described herein,particularly from the perspective of the trusted device. For example, anon-generic, specifically configured device (e.g., device 200) mayperform procedure 2600 by executing stored instructions (e.g., process248). The procedure 2700 may start at step 2705, and continues to step2710, where, as described in greater detail above, a “first” device (nowthe “trusted” device) may receive an encrypted private key of a seconddevice encrypted using a public key of the first device, where thesecond device encrypted data into encrypted data using a public key ofthe second device and stored the encrypted data on a storage server. Instep 2715, the first device decrypts a private key of the second devicefrom the encrypted private key using a private key of the first device.In step 2720, the first device accesses the encrypted data on thestorage server by utilizing the private key of the second device. Thesimplified procedure may then end in step 2725.

Other steps may also be included generally within procedure 2700. Forexample, such steps (or, more generally, such additions to steps alreadyspecifically illustrated above), may include modifying the data accessedfrom the storage server into modified data, encrypting the modified datawith the public key of the first device and the public key of the seconddevice, and storing the modified data on the storage server. Additionalsteps may further include encrypting the private key of the first devicewith the public key of the second device, sending the private key of thefirst device encrypted with the public key of the second device to thesecond device to enable die second device to use the private key of thesecond device to decipher the private key of the first device; and soon.

In accordance with one embodiment, the public keys and the encrypteddata are shared between the two devices via wired or wirelesscommunication channels. In accordance with another embodiment, data,e.g., the keys and the encrypted keys, is exchanged between the twodevices by optical transfer of information, such as, e.g., by one deviceencoding the data using a QR code and the other device using its camerato detect and decipher the QR code.

In addition, in still further embodiments, additional devices (e.g., athird device, a fourth device, and so on) may also participate in thesharing of keys and data as described above. For instance, each devicemay share its private keys within the trusted group of devices, and/oreach device may have a singular joint/common computed key pair to usefor encrypting and decrypting the data, accordingly.

According to the embodiments herein, an illustrative method herein maycomprise: encrypting, by a first device, data into encrypted data usinga public key of the first device, storing, by the first device, theencrypted data on a storage server, encrypting, by the first device, aprivate key of the first device into an encrypted private key using apublic key of a second device, and communicating, from the first device,the encrypted private key of the first device to the second device,wherein the second device is configured to access the encrypted data onthe storage server based on decrypting the encrypted private key of thefirst device by utilizing a private key of the second device andutilizing the private key of the first device to access the encrypteddata stored on the storage server.

In one embodiment, the second device modifies the data accessed from thestorage server into modified data, encrypts the modified data with thepublic key of the first device and the public key of the second device,and stores the modified data on the storage server. In one embodiment,the method further comprises: receiving from the second device, aprivate key of the second device encrypted with the public key of thefirst device, and deciphering the private key of the second device usingthe private key of the first device. In one embodiment, the methodfurther comprises: accessing the modified data stored by the seconddevice on the server using the private key of the first device and theprivate key of the second device. In one embodiment, the method furthercomprises: receiving a notification when the data is modified by thesecond device, and retrieving the modified data from the server beforeremodifying the data in response to the notification. In one embodiment,the method further comprises: retrieving the data from the server beforeremodifying the data every time the data is remodified.

In one embodiment each device that needs access to the data on thestorage server has a joint private key and a joint public key to use fordeciphering and encrypting the data on the storage server. In oneembodiment, the method further comprises: establishing the joint privatekey and the joint public key; and exchanging the joint private key andthe joint public key with each device that needs access to the data onthe storage server.

In one embodiment, the first device and the second device belong to thesame user.

In one embodiment, the first device and the second device belong todifferent owners with established trust.

In one embodiment, the method further comprises: sending the public keyof the first device to the second device, and receiving the public keyof the second device from the second device.

In one embodiment, communicating the encrypted private key to the seconddevice using an optical transfer exchange. In one embodiment, the methodfurther comprises: utilizing a QR code to facilitate the opticaltransfer exchange.

In one embodiment, the method further comprises: generating a hash ofthe data, and sending the hash to the second device, wherein the seconddevice provides the hash to the storage server to prove the seconddevice is authorized to modify the data.

According to the embodiments herein, an illustrative tangible,non-transitory, computer-readable medium herein may havecomputer-executable instructions stored thereon that, when executed by aprocessor on a computer, may cause the computer to perform a methodcomprising: encrypting, by a first device, data into encrypted datausing a public key of the first device, storing, by the first device,the encrypted data on a storage server, encrypting, by the first device,a private key of the first device into an encrypted private key using apublic key of a second device, and communicating, from the first device,the encrypted private key of the first device to the second device,wherein the second device is configured to access the encrypted data onthe storage server based on decrypting the encrypted private key of thefirst device by utilizing a private key of the second device andutilizing the private key of the first device to access the encrypteddata stored on the storage server.

Further, according to the embodiments herein an illustrative apparatusherein nay comprise: one or more network interfaces to communicate witha network; a processor coupled to the network interfaces and configuredto execute one or more processes: and a memory configured to store aprocess that is executable by the processor, the process, when executed,configured to: encrypt, by a first device, data into encrypted datausing a public key of the first device, store, by the first device, theencrypted data on a storage server, encrypt, by the first device, aprivate key of the first device into an encrypted private key using apublic key of a second device, and communicate, from the first device,the encrypted private key of the first device to the second device,wherein the second device is configured to access the encrypted data onthe storage server based on decrypting the encrypted private key of thefirst device by utilizing a private key of the second device andutilizing the private key of the first device to access the encrypteddata stored on the storage server.

According to the embodiments herein, another illustrative method hereinmay comprise: receiving, at a first device, an encrypted private key ofa second device encrypted using a public key of the first device,wherein the second device encrypts data into encrypted data using apublic key of the second device and stored the encrypted data on astorage server, decrypting, by the first device, a private key of thesecond device from the encrypted private key using a private key of thefirst device, and accessing, by the first device, the encrypted data onthe storage server by utilizing the private key of the second device.

In one embodiment, the method further comprises: modifying the dataaccessed from the storage server into modified data, encrypting themodified data with the public key of the first device and the public keyof the second device, and storing the modified data on the storageserver. In one embodiment, the method further comprises: encrypting theprivate key of the first device with the public key of the seconddevice, and sending the private key of the first device encrypted withthe public key of the second device to the second device to enable thesecond device to use the private key of the second device to decipherthe private key of the first device. In one embodiment, the seconddevice uses the private key of the second device and the private key ofthe first device to access the modified data stored on the server by thefirst device. In one embodiment, a notification is sent to the seconddevice when the data is modified by the first device so that the seconddevice may retrieve the modified data from the server before the seconddevice remodifies the data. In one embodiment, the method furthercomprises: retrieving the data from the server before remodifying thedata every time the data is remodified.

In one embodiment, each device that needs access to the data on thestorage server has a joint private key and a joint public key to use fordeciphering and encrypting the data on the storage server. In oneembodiment, the method further comprises: receiving the joint privatekey and the joint public key from the second device.

In one embodiment, the first device and the second device belong to thesame user. In one embodiment, the first device and the second devicebelong to different owners with established trust.

In one embodiment, the method further comprises: sending the public keyof the first device to the second device; and receiving the public keyof the second device from the second device.

In one embodiment, the method further comprises: receiving the encryptedprivate key to the second device using an optical transfer exchange. Inone embodiment, the method further comprises: utilizing a QR code tofacilitate the optical transfer exchange.

In one embodiment, the method further comprises: receiving a hash of thedata from the second device, and providing the hash to the storageserver to prove the first device is authorized to modify the data.

According to the embodiments herein, an illustrative tangible,non-transitory, computer-readable medium herein may havecomputer-executable instructions stored thereon that, when executed by aprocessor on a computer, may cause the computer to perform a methodcomprising: receiving, at a first device, an encrypted private key of asecond device encrypted using a public key of the first device, whereinthe second device encrypts data into encrypted data using a public keyof the second device and stored the encrypted data on a storage server,decrypting, by the first device, a private key of the second device fromthe encrypted private key using a private key of the first device, andaccessing, by the first device, the encrypted data on the storage serverby utilizing the private key of the second device.

Further, according to the embodiments herein another illustrativeapparatus herein may comprise: one or more network interfaces tocommunicate with a network; a processor coupled to the networkinterfaces and configured to execute one or more processes; and a memoryconfigured to store a process that is executable by the processor, theprocess, when executed, configured to receive, at a first device, anencrypted private key of a second device encrypted using a public key ofthe first device, wherein the second device encrypts data into encrypteddata using a public key of the second device and stored the encrypteddata on a storage server, decrypt, by the first device, a private key ofthe second device from the encrypted private key using a private key ofthe first device, and access, by the first device, the encrypted data onthe storage server by utilizing the private key of the second device.

The techniques described herein, therefore, provide for zero-knowledgedata management, that is, the secure management of server-stored datathat is viewable only by intended recipients, which can be selectedeither along with or after storage of the data. In particular, thetechniques herein provide for storage of information in a manner thatprevents the storage servers storing the data from understanding ordeciphering the data, as well as a manner for creating reporting basedon information that the storage servers (or other report-triggeringentities) cannot see. In this way, even in the event of a compromisedstorage server, the techniques herein prevent data leakage, since thestored data cannot be decrypted by the storage server (nor is theinformation/keys necessary to decrypt the encrypted data stored on thestorage server).

Furthermore, the techniques herein address the capability of usingmultiple devices for accessing concealed information. In particular,where multiple trusted devices may be employed by a singular user, or bya secure group of users (e.g., spouses, admins, business partners,etc.), the techniques herein allow the frictionless sharing of neededencryption keys between the devices in order to allow both access andmodification of the securely stored data, still while preventingunauthorized access to the data by third parties or the storage serveritself.

Illustratively, the techniques described herein may be performed byhardware, software, and/or firmware, such as in accordance with aprocess, which may include computer executable instructions executed bya processor (of a particular correspondingly operative computing device)to perform functions relating to the techniques described herein, e.g.,in conjunction with other devices which may have a correspondinglyconfigured processes depending upon the functionality of the device, asdescribed below (e.g., a user device, a storage server, a controllerdevice, an attestation service, and so on).

It should also be noted that the steps shown and described in theprocedures above are merely examples for illustration, and certain othersteps may be included or excluded as desired. For instance, other stepsmay also be included generally within procedures above as describedherein. Further, while a particular order of the steps is shown, thisordering is merely illustrative, and any suitable arrangement of thesteps may be utilized without departing from the scope of theembodiments herein. Moreover, while procedures may be describedseparately, certain steps from each procedure may be incorporated intoeach other procedure, and the procedures are not meant to be mutuallyexclusive.

While there have been shown and described illustrative embodiments thatrelate generally to zero-knowledge data management networks, andparticularly to using multiple devices to access concealed information,it is to be understood that various other adaptations and modificationsmay be made within the scope of the embodiments herein. For example,though the disclosure was often described with respect to using publicand private keys, those skilled in the art should understand that thiswas done only for illustrative purpose and without limitations, and thetechniques herein may use any asymmetric encryption technique withencryption and decryption keys or techniques. The embodiments herein arealso applicable to any other arrangement of source/server/recipient notspecifically mentioned herein, such as hierarchical storage ofinformation (e.g., a recipient may be another storage server), or wherethe source device is also the storage server (e.g., obtaining the data,storing the data in a secure manner, and re-encrypting the data forparticular recipients as needed). In particular, though financialtransactions (e.g., especially currency transaction reports (CTRs)) wereused as a primary example throughout much of the description above, theembodiments herein are not so limited. Moreover, references to serversor devices not being able to gain access to specific source data 415 mayalso imply herein that in addition to the server itself not being ableto access and process the source data, neither authorized norunauthorized people who otherwise have full access to a specific serverwould have access to the source data 415 residing on that server.

Furthermore, while the embodiments may have been demonstrated withrespect to certain communication environments, physical environments, ordevice form factors, other configurations may be conceived by thoseskilled in the art that would remain within the contemplated subjectmatter of the description above. For example, while different functionshave been described as being performed on various servers or devices,certain functions may be performed on the same physical server or on thesame virtual server (e.g., the storage server 420 and attestation server1510 may be different co-located functions on a same physical/virtualserver). Also, some functions which were described separately (e.g., anddistributed between different servers) may be performed by a singleprocess (e.g., a single software program configured to perform multiplefunctions described herein).

Notably, as described herein, any “device” may generally imply anydevice with appropriate credentials or authority to act on behalf of aparticular entity. For example, a “source device” may imply any of oneor more source devices, such as a smartphone, tablet, computer, etc., ofa particular user, company, institution, etc., that has the necessaryencryption keys to create source-encrypted source data, and so on. Assuch, a “source” herein may imply any of one or more source devices thatis authorized as a source of source data (e.g., a user logged into anyone of his or her devices). Likewise, a “particular recipient device”may imply any of one or more recipient devices authorized to receivedata, e.g., any device with the necessary credentials and decryptionkeys (e.g., recipient private keys). Similar understanding will bereadily made by those skilled in the art to include such devices as oneor more storage servers, one or more attestation servers, one or morecontroller devices, one or more governmental devices, one or moreregulatory compliance/organization devices, one or more financialinstitution devices, one or more retail company devices, one or moreauditing system devices, one or more medical system devices, one or moreuser devices, and so on. As such, the description herein, as well as theappended claims, are meant to include any appropriate configuration ofauthorized devices acting on behalf of a named entity (e.g., a serverfarm as opposed to a single server, any number of a user's many devices,etc.).

The foregoing description has been directed to specific embodiments. Itwill be apparent, however, that other variations and modifications maybe made to the described embodiments, with the attainment of some or allof their advantages. For instance, it is expressly contemplated thatcertain components and/or elements described herein can be implementedas software being stored on a tangible (non-transitory)computer-readable medium (e.g., disks/CDs/RAM/EEPROM/etc.) havingprogram instructions executing on a computer, hardware, firmware, or acombination thereof. Accordingly this description is to be taken only byway of example and not to otherwise limit the scope of the embodimentsherein. Therefore, it is the object of the appended claims to cover allsuch variations and modifications as come within the true intent andscope of the embodiments herein.

What is claimed is:
 1. A method, comprising: receiving, at a firstdevice, an encrypted private key of a second device encrypted using apublic key of the first device, wherein the second device encrypts datainto encrypted data using a public key of the second device and storedthe encrypted data on a storage server; decrypting, by the first device,a private key of the second device from the encrypted private key usinga private key of the first device; and accessing, by the first device,the encrypted data on the storage server by utilizing the private key ofthe second device.
 2. The method as in claim 1, further comprising:modifying the data accessed from the storage server into modified data;encrypting the modified data with the public key of the first device andthe public key of the second device; and storing the modified data onthe storage server.
 3. The method of claim 2, further comprising:encrypting the private key of the first device with the public key ofthe second device; and sending the private key of the first deviceencrypted with the public key of the second device to the second deviceto enable the second device to use the private key of the second deviceto decipher the private key of the first device.
 4. The method of claim3, wherein the second device uses the private key of the second deviceand the private key of the first device to access the modified datastored on the storage server by the first device.
 5. The method of claim2, wherein a notification is sent to the second device when the data ismodified by the first device so that the second device may retrieve themodified data from the storage server before the second deviceremodifies the data.
 6. The method of claim 2, further comprising:retrieving the data from the storage server before remodifying the dataevery time the data is remodified.
 7. The method of claim 1, whereineach device that needs access to the data on the storage server has ajoint private key and a joint public key to use for deciphering andencrypting the data on the storage server.
 8. The method of claim 7,further comprising: receiving the joint private key and the joint publickey from the second device.
 9. The method of claim 1, wherein the firstdevice and the second device belong to a same user.
 10. The method ofclaim 1, wherein the first device and the second device belong todifferent owners with established trust.
 11. The method of claim 1,further comprising: sending the public key of the first device to thesecond device; and receiving the public key of the second device fromthe second device.
 12. The method of claim 1, further comprising:receiving the encrypted private key to the second device using anoptical transfer exchange.
 13. The method of claim 12, furthercomprising: utilizing a QR code to facilitate the optical transferexchange.
 14. The method of claim 1, further comprising: receiving ahash of the data from the second device; and providing the hash to thestorage server to prove the first device is authorized to modify thedata.
 15. A tangible, non-transitory, computer-readable medium havingcomputer-executable instructions stored thereon that, when executed by aprocessor on a computer, cause the computer to perform a methodcomprising: receiving, at a first device, an encrypted private key of asecond device encrypted using a public key of the first device, whereinthe second device encrypts data into encrypted data using a public keyof the second device and stored the encrypted data on a storage server;decrypting, by the first device, a private key of the second device fromthe encrypted private key using a private key of the first device; andaccessing, by the first device, the encrypted data on the storage serverby utilizing the private key of the second device.
 16. The tangible,non-transitory, computer-readable medium of claim 15, wherein the methodfurther comprises: modifying the data accessed from the storage serverinto modified data; encrypting the modified data with the public key ofthe first device and the public key of the second device; and storingthe modified data on the storage server.
 17. The tangible,non-transitory, computer-readable medium of claim 16, wherein the methodfurther comprises: encrypting the private key of the first device withthe public key of the second device; and sending the private key of thefirst device encrypted with the public key of the second device to thesecond device to enable the second device to use the private key of thesecond device to decipher the private key of the first device.
 18. Thetangible, non-transitory, computer-readable medium of claim 17, whereinthe second device uses the private key of the second device and theprivate key of the first device to access the modified data stored onthe storage server by the first device.
 19. The tangible,non-transitory, computer-readable medium of claim 15, wherein eachdevice that needs access to the data on the storage server has a jointprivate key and a joint public key to use for deciphering and encryptingthe data on the storage server.
 20. An apparatus, comprising: one ormore network interfaces; a processor coupled to the one or more networkinterfaces and configured to execute one or more processes; and a memoryconfigured to store a process that is executable by the processor, theprocess when executed configured to: receive, at a first device, anencrypted private key of a second device encrypted using a public key ofthe first device, wherein the second device encrypts data into encrypteddata using a public key of the second device and stored the encrypteddata on a storage server; decrypt, by the first device, a private key ofthe second device from the encrypted private key using a private key ofthe first device; and access, by the first device, the encrypted data onthe storage server by utilizing the private key of the second device.